Workload Identity Federation
Workload Identity Federation allows you to access Microsoft Entra protected resources without needing to manage secrets (for supported scenarios).
Workload Identity Federation uses OpenID Connect to create a trust relationship between an external Identity Provider and a user-assigned managed identity or application in Microsoft Entra ID. Workload Identity Federation ensures that we don't have to manage secrets any longer, like we would have done previously.
The work flow for exchanging an external token for an access token is described in the image below:
The external workload (such as a GitHub Actions workflow) requests a token from the external Identity Provider (such as GitHub, Azure DevOps or other public clouds such as GCP / AWS).
The external Identity Provider issues a token to the external workload.
The external workload (the login action in a GitHub workflow, for example) sends the token to Microsoft Identity Platform and requests an access token.
Microsoft Identity Platform checks the trust relationship on the user-assigned managed identity or app registration and validates the external token against the OpenID Connect (OIDC) issuer URL on the external Identity Provider.
When the checks are satisfied, Microsoft Identity Provider issues an access token to the external workload.
The external workload accesses Microsoft Entra protected resources using the access token from Microsoft Identity Provider. The external workload uses the access token to interact with Azure resources.
Using Workload Identity Federation With Azure DevOps
Azure DevOps uses Service Connections to allow interaction with external services, e.g. for deploying resources to Azure. Service Connections can be made to numerous services, for example to connect to Azure we would use Azure Resource Manager (ARM).
Until September 2023, for ARM connections, we would have used either a Service Principal or a Managed Identity, however, since that date, Workload Identity Federation has been in Public Preview with targeted General Availability in Q1 2024. The options, once you select ARM on the above dialog are:
You can see that Workload Identity Federation (automatic) is now the recommended choice.
If we choose that option and press Next we see something like this:
We choose the appropriate Scope, Resource Group, Name and description and also whether we want to grant access permission to all pipelines and then press Save to create the Service Connection.
The Service Connection now exists, using Workload Identity Federation:
If we click on the Service Connection we see:
And if we click on Manage Service Principal we can see the App Registration that has been created for us:
The name of the App Registration is of the format:
<Azure DevOps Organisation>-<Azure DevOpsProject>-<GUID>
If we look under Secrets we would see:
If we click on the secret we see something like this:
These details are specific to the external Identity Provider, in this case Azure DevOps.
That Service Connection is now ready to use in our Pipelines and will not require any form of Secrets maintenance going forwards.
it is also possible, with some documented caveats, to convert an existing ARM Service Connection to use Workload Identity Federation, e.g. instead of a Service Principal. If you click on an existing ARM Service Connection which does not use Workload Identity Federation you see:
If you click on Convert, Azure DevOps will convert it to Workload Identity Federation for you
You are given a notification that you can revert within 7 days and that existing Secrets will be deleted. Click on Convert to convert the Service Connection. It can take a few minutes...
When finished, the conversion message disappears and you can then click on the Service Connection to see something like this:
This one happens to be for a Management Group.
Hope you find this useful.
References
Create an Azure Resource Manager service connection using workload identity federation
Convert an existing ARM service connection to use workload identity federation
Introduction to Azure DevOps Workload identity federation (OIDC) with Terraform
Workload identity federation for Azure Pipelines public preview
Comentarios