Workload Identity Federation, how does this work?
If you haven’t seen it yet, workload identity federation gives some unique capabilities. It enables CI/CD to be used without secrets to the target (cloud) environment.
The technology enables an OpenID Connect (OIDC) token to be exchanged for another token issued by another identity provider. One of the current supported scenarios is having a Github Action creating a shortlived OIDC token and exchanging it for an Azure AD token to access Azure resources. This means there is no secret or certificate inside of Github to access Azure resources anymore. It relies on having an Azure AD app registration trusting Github as the token issuer.
The flow looks like this, where External Workload is the Github Action and External Provider is Github:
To use this feature, one way to configure Azure AD is to create an App registration (with corresponding SPN / enterprise app). Configure the SPN to have the necessary permissions within Azure to deploy resources.
To configure Azure AD to trust GitHub, check out the Microsoft documentation. The steps are basically to fill in the following list in an Azure AD App Registration: In this case the entity type is set as Environment, but Pull Request, Branch and Tag are other options.
The same technique is already used for some time by AKS as announced here. the Kubernetes cluster becomes a token issuer, issuing tokens to Kubernetes Service Accounts. These service account tokens can be configured to be trusted by Azure AD to access Azure resources.
As described on the Azure DevOps public roadmap the feature Secret-free deployments from Azure Pipelines (preview) is on its way and should be ready this quarter. It uses the same technology as GitHub.
“Once implemented, this mechanism will be recommended in the product over other types of Azure service connections that exist today”
By the way, it not only works for Azure, but for all OIDC compliant service providers.
All in all, this new mechanism makes way for much safer environments as there are less secrets in general.
In my next blog post I’ll show how this new capability enables developers / DevOps engineers to move faster.