Howdy folks,
As we’ve all experienced, the entire world is going digital and increasingly everything is connected to the cloud. For most of you, this means your organizations are creating and using more software than ever before and most of it is running as a workload in a cloud somewhere.
These software workloads typically need to access resources in the cloud, things like Azure storage or key vault or documents and email in Microsoft Graph. And to do that, these software workloads need to be able to authenticate, just like users. This creates a big challenge for developers, DevOps, and administrators. They need to deal with the secrets necessary to authenticate this access. These secrets must be stored securely and rotated frequently. Secrets management is becoming more challenging for many organizations, especially with the increasing number of software workloads that need to access other resources.
We’ve added a new public preview capability in Azure AD called workload identity federation to minimize the need for these secrets. It’s useful when your software workload is running in an environment where you can’t use managed identities in Azure. This capability allows you to access Azure AD protected resources such as Azure and Microsoft Graph without needing secrets! You can configure Azure AD to trust tokens issued to your software workload by another identity provider. Your software workloads can then use these tokens to get Azure AD tokens and access Azure and Graph resources.
Here are some scenarios where you can use this workload identity federation capability today:
- GitHub Actions workflows to achieve CI/CD with Azure: rather than store an Azure AD secret in your GitHub repository, you can use GitHub tokens to authenticate and deploy your services to Azure. (See GitHub documentation for more details)
- Services running in Kubernetes clusters: you can use tokens issued to your service accounts by Kubernetes clusters to access Azure resources. Azure AD workload identity for Kubernetes is an open-source project which guides the use of this capability in your Kubernetes cluster, no matter where it is running.
- Services using SPIFFE/SPIRE for their workload identities: if you use SPIFFE/SPIRE for identities needed by your software workloads, you can use the SPIFFE tokens to access Azure resources.
- Services running in Google Cloud Platform: using the identity token issued to a Google service account, your software workload running in GCP (Google Cloud Platform) can access Azure resources without additional secrets.
These blog posts from Uday Hegde, a member of my team, walk through each of these scenarios:
We will continue to expand the scenarios where you can achieve this kind of secret-less authentication.
Learn more about Azure AD workload identity federation at our documentation page.
As always, we’d love to hear any feedback or suggestions you may have. Please let us know what you think in the comments below or on the Azure AD feedback forum.
Best regards,
Alex Simons (Twitter: @Alex_A_Simons)
Corporate Vice President of Program Management
Microsoft Identity Division
Learn more about Microsoft identity:
