Introduction
Today we will take a closer look at the relatively new topic of workload identity federation from Microsoft. Microsoft is increasingly recommending switching to the workload identity federation, but rarely does it really explain what the benefits are and, above all, for which scenarios it makes or doesn’t make sense.
What is workload identity Federation?
Workload identity federation is a feature of Entra ID that allows applications running on non-Azure services to authenticate and access Azure resources using Managed Identities.
In other words, it allows you to use tokens from external systems like AWS, Google Cloud Platform, or on-premises Active Directory to authenticate applications. This eliminates the need to manage and rotate secrets, thereby enhancing the security of your applications.
This feature is particularly useful for hybrid cloud scenarios where you have workloads running on-premises or on other cloud platforms that need to interact with Microsoft Entra protected services. It simplifies the process of managing identities for your applications and provides a more secure way to control access to your Microsoft Entra resources.
Why now workload identity federation ?
Traditionally, software applications that are operated outside your Microsoft organisation can access protected Microsoft Entra resources using a so-called Application registration with client id and client secret.
One of the big pains is that the secrets expire at a defined interval and you realise it too late. As you find out too late, your productive workload is impaired as it no longer works when the secret expires.
Microsoft workload identity federation does exactly that for you. It is no longer necessary to rotate secrets in a defined period of time. This saves you a lot of work in day-to-day operations. As we all know, more and more applications will use Microsoft Entra as their identity provider (IdP) or applications will want to access protected Microsoft Entra (Azure, Microsoft Graph, Microsoft 365, or third-party) resources.
Important to know
Workloads that are operated within Microsoft Azure can authenticate within their own Microsoft organization using managed identities and do not require workload identity federation or application registration.
How it works
- The external workload (such as a GitHub Actions workflow) requests a token from the external IdP (such as GitHub).
- The external IdP 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 IdP.
- When the checks are satisfied, Microsoft identity platform issues an access token to the external workload.
- The external workload accesses Microsoft Entra protected resources using the access token from Microsoft identity platform. A GitHub Actions workflow, for example, uses the access token to publish a web app to Azure App Service.
Good to know
The Microsoft identity platform can only store the first 100 signing keys obtained from the external Identity Provider’s (IdP’s) OIDC endpoint. If the external IdP has more than 100 signing keys, you might encounter errors when using workload identity federation.
Source: Workload identity federation – Microsoft Learn
Which setups are now supported ?
The following setups are supported for accessing Microsoft Entra protected resources using workload identity federation:
- Kubernetes workloads
- Establish a trust relationship between your Microsoft Entra identity and a Kubernetes workload, regardless of the cluster (AKS, EKS, GKE, or on-premises).
- GitHub Actions
- Set up a trust relationship between your Entra identity and a GitHub repo.
- Google Cloud
- Set up a trust relationship between your Entra identity and a Google Cloud identity.
- AWS workloads
- Set up a trust relationship between your Entra identity and an Amazon Cognito identity.
- Other external workloads
- Establish a trust relationship between your Entra identity and the external IdP for your platform. Use tokens from that platform to authenticate with Microsoft and call Microsoft APIs.
- SPIFFE and SPIRE
- Set up a trust relationship between your Entra identity and a SPIFFE ID for an external workload.
- Azure Pipelines (Preview)
- Create a new Azure Resource Manager service connection using workload identity federation.
My personal thoughts
At the moment, the workload identity federation option/possibility is not yet very popular in my mind. The classic way with client id and client secret is still very well known and has proven to be very robust over the last few years. Sure, the security with the regular changing of the secret is a big pain, but in the meantime we have come to terms with it.
Personally, I have had my first experiences with Azure Pipelines, which work well as long as your DevOps org is deployed in the tenant you want to connect to. As soon as you want to run pipelines in another tenant, then at this point in time it’s over with workload identity federation.
I am sure that the future will tell. From a security perspective, I can warmly recommend it, but not yet from an application perspective, as adjustments are necessary.
I will go into further detail in another blog post.
Ressources