Azure DevOps Workload Identity Federation

Developer Support

October 31st, 20230 0

With the recent arrival of the Public preview of Workload identity federation for Azure Pipelines, you may be wondering how to efficiently migrate dozens or even hundreds of ARM Service Connections to take advantage of these benefits. In this post, Emmanuel Knafo dives right in.

Updating Your Azure DevOps ARM Service Connections To Use The Recommended Workload Identity Federation

With the recent arrival of the Public preview of Workload identity federation for Azure Pipelines, you may be wondering how to efficiently migrate my dozens or even hundreds of ARM Service Connections to take advantage of these main benefits:

Simplified management: You do not need to generate, copy, and store secrets from service principals in Azure Entra ID to Azure DevOps anymore. Secrets that are used in other authentication schemes of Azure service connections (e.g., service principal) expire after a certain period (2 years currently). When they expire, pipelines fail. You have to generate a new secret and update the service connection. Switching to workload identity federation eliminates the need to manage these secrets and improves the overall experience of creating and managing service connections.
Improved security: With workload identity federation, the federation subject sc://<org>/<project>/<service connection name> uniquely identifies what the identity can be used for, which provides a better constraint than a (shared) secret. There is no persistent secret involved in the communication between Azure Pipelines and Azure. As a result, tasks running in pipeline jobs cannot leak or exfiltrate secrets that have access to your production environments. This has often been a concern for our customers.