Workload Identity Federation
Anatoly Mironov
There is no reason not to switch to Workload Identity Federation for Service Connections in Azure DevOps. Compared to secret-based connections, it offers several compelling benefits:
- Firstly, you eliminate the need for secrets. This means no more manual or automatic rotation of secrets, or worse, being caught off guard when secrets expire unnoticed.
- Secondly, it’s more secure. Secrets used across multiple projects and stored in key vaults or, even worse, in tools like OneNote, are far more susceptible to compromise than the new identity federation approach.
Here is my step-by-step guide on setting up Workload Identity Federation in Azure DevOps. I recommend the manual setup over the automatic one for these reasons:
- It provides greater control over the service principal. You might want to adhere to a naming policy or use the same app registration/service principal for related Azure DevOps Projects. However, it’s advisable to use different service principals and service connections for different environments: dev, test, prod.
- It’s the only option if the creation of app registrations in your Entra ID is restricted, which is a best practice.
Setting up Service Connections with WIF
For this process, keep Azure DevOps and Azure Portal open in separate tabs for easy value transfer.
1. Start a new Service Connection
In Azure DevOps, navigate to Settings > Service Connections and click “New Service Connection”. Select “Azure Resource Manager”.
In the following dialog, choose “Workload Identity Federation (manual)”.
Name the connection appropriately, indicating the subscription and environment it points to (e.g., DEV, TEST, PROD). Remember, a service connection cannot span multiple Azure subscriptions or Azure DevOps Projects.
And, you can also tick the Grant access permisssion to all pipelines. I usually do it, but it depends of course. Sometimes you want to control access to the service connection more granually, even within a project in Azure DevOps. Optionally, you can select Grant access permisssion to all pipelines. This depends on whether you want to control access more granularly within a project.
2. Prepare the app registration
Switch to the Azure Portal tab.
Go to “Entra ID” > App Registrations, and click “New Registration”. Name it according to your policies. For simplicity, I’ll name mine devops-prod. Choose the first option for account types.
3. Copy the Issuer and Identifier
Back in Azure DevOps, in the Service Connection Creation dialog, note the Issuer and Subject Identifier.
In the App Registration tab, navigate to “Certificates and Secrets” > “Federated credentials” and click “Add credential”.
In the dialog, select “Other issuer” for Federated Credential Scenario and copy the Issuer and Subject Identifier from Azure DevOps. Name it appropriately for easy identification.
4. Grant permissions
Your new service principal needs specific rights to your subscription or resource group. In the Azure Portal, select “Access control (IAM)” and add a role assignment, choosing Contributor and your new app registration/service principal.
5. Copy the Service Principal Information
Transfer the app id and tenant id from Azure Portal to Azure DevOps.
6. Copy the Azure Subscription Information
In Azure Portal, open your Azure Subscription, copy the ID and name to Azure DevOps.
7. Save
In Azure DevOps, keep the default “Azure Cloud” and “Subscription level” settings in the Service Connection dialog, unless other settings are required.
Click on Verify and Save. Congratulations, you’re done!
