Microsoft Entra Workload Identity Federation is a hidden gem when dealing with app registrations and service principals because it will significantly improve the security posture of your workload identities. While I already blogged about the more technical and implementation specific details in my GitHub Actions with Entra Workload Identity Federation post, I want to highlight the benefits and scenarios where you can use Workload Identity Federation to access Entra ID protected resources.
Quick recap on Workload Identities
Should you read this post and wonder what a Workload Identity is, here a quick recap:
- A workload identity (can be either a managed identity or service principal) is used to access resources protected by Entra ID (Azure AD) from a service or automation
- A service principal is an instance of an app registration. To leverage a service principal authentication with either a client secret, certificate, or federated credential is required.
- A managed identity is a Microsoft managed identity of a resource such as a Logic App, Automation Account or VM. Microsoft manages the credentials of those managed identities. This allows for secure access as the credentials are not exposed to other services.
Managed Identity is the recommended type for workload identities for workloads that live in the Microsoft Azure ecosystem. For services and automations outside of Azure, service principals (app registrations) are the only option. The usage and credential configuration is unfortunately not a simple process.
Why should I use Workload Identity Federation?
Credential exposure of workload identities can lead to serious compromise depending on the configured permissions.
As Salesforce [1] nicely concludes: “One of the most common breaches of data security comes from sensitive data stored in the code you develop”.
Credential exposure can occur in different ways. One of the simplest examples might be the following:
Other examples are client secrets or certificates stored in plain text, optionally with wrong access control list configurations or including such things in version control or (accidentally) leaking this information.
Regularly we use the following client credentials on workload identities:
- Client Secret
- Certificate
Both credential types are subject to exposure, although a certificate provides additional security benefits when stored securely. Also for client secrets, the procedure can be improved by storing it in a secure location such as Azure Key Vault (the key vault could then also be used to exchange the information instead of Teams chat 🙃).
For both credential types, renewal is required as they have an expiration date. Furthermore, the creator of the credentials has potential knowledge of them which makes also rotation an important need.
The better alternative — Workload Identity Federation
Workload identity federation is better in the above mentioned aspects, because it eliminates long-lived credentials or secrets and the exchange of such information.
What does “Workload identity Federation” now mean? Workload identity Federation is a new type of authentication that can be used to acquire the identity of a workload identity.
Federation (in a simplified manner) means, that an external Identity Provider (IdP) issues a token, that is valid for the authentication. A trust to the external IdP is configured, directly on the app registration.
Instead of a fixed set of credentials (compared to client secret or a certificate) the federation serves as a trust anchor and credential exposure is dramatically reduced as only short-lived tokens are exchanged.
Open ID Connect is used as authentication protocol and tokens are signed by the external IdP.
An example for a GitLab pipeline accessing Azure resource such as an app server for a deployment might look like this:
- The admin configures the app registration and registers the information for the workload identity federation in Entra ID
- During pipeline execution, the pipeline will acquire an access token (JWT) from the GitLab IdP (your GitLab server)
- The pipeline performs authentication agains Entra ID. Entra ID verifies the issuer and other information of the token with the configured federation options on the workload identity
- If the token matches with the configuration, Entra ID issues an access token. The pipeline successfully acquired the identity of the workload identity
- The pipeline can now access protected resources such as the Azure app service
When can I use Workload Identity Federation?
Which scenarios support “Workload identity Federation”?
- Workloads running on any Kubernetes cluster (Azure Kubernetes Service (AKS), Amazon Web Services EKS, Google Kubernetes Engine (GKE), or on-premises)
- GitHub Actions (CI / CD Pipelines) [2]
- GitLab (CI / CD Pipelines) [3]
- Workloads / VMs Google Cloud
- Workloads / VMs running in Amazon Web Services (AWS)
- Workloads supporting SPIFFE and SPIRE [4]: that’s basically an open standard for authentication scenarios between cloud services
Recommended Actions
Some pro tipps to round up this post:
- Use managed identities whenever possible
- When using app registrations make sure to use Federated credentials or a certificate (client secrets as a last resort)
- Review existing app registrations and check whether you could switch to workload identity federation
- Consider the security of the different credential types and include this as a quality aspect when developing or integration new applications
/ Cheers and happy workload identity federation!
