Azure Workload Identity Federation with Microsoft Entra

Azure Workload Identity Federation with Microsoft Entra is a game-changer for organizations looking to simplify their identity management.

This solution eliminates the need for service principal credentials, reducing the attack surface of your Azure resources.

By integrating with Azure Active Directory (Azure AD), Microsoft Entra enables secure authentication and authorization for your workloads.

Microsoft Entra provides a centralized platform for managing identities and access, making it easier to scale and manage your Azure resources.

To configure workload identity, you need to create a user-assigned managed identity, which requires an Azure subscription and the "Managed Identity Contributor" role.

You can use the Azure identity SDK with the DefaultAzureCredential for either application or managed identities, which uses environment variables setup by the webhook to determine which identity to get a token for.

To establish a trust relationship, you can configure a workload identity federation with your user-assigned managed identity or app registration in Microsoft Entra ID and the external IdP of the platform you wish to trust.

Using tokens issued by that platform, typically called SVID tokens, you can authenticate with the Microsoft identity platform and call APIs in the Microsoft ecosystem.

To get started, navigate to the Azure portal and locate the newly created application, then go to "API permissions" and select "Grant admin consent" for the requested permissions.

You can also use the client credentials grant flow, using a client_assertion from the IdP, to get an access token from the Microsoft identity platform, passing in the identity provider’s JWT instead of creating one yourself using a stored certificate.

This setup allows you to authenticate software workloads to Entra ID without managing secrets or certificates, making it easier to integrate with Entra Workload Identity into existing infrastructure.

Azure Identity client libraries offer three approaches to authentication: using DefaultAzureCredential, creating a ChainedTokenCredential instance, or using WorkloadIdentityCredential directly. The minimum package version required for each language ecosystem's client library varies, as shown in the following table:

DefaultAzureCredential uses environment variables injected by the Azure Workload Identity mutating webhook to authenticate with Azure Key Vault.

Azure Identity Client Libraries are a crucial part of Azure Identity and Authentication. You can use DefaultAzureCredential, which attempts to use the WorkloadIdentityCredential, to authenticate with Azure Key Vault.

The Azure Identity client libraries have different approaches to authentication, including using DefaultAzureCredential, creating a ChainedTokenCredential instance that includes WorkloadIdentityCredential, or using WorkloadIdentityCredential directly.

Here's a summary of the minimum package version required for each language ecosystem's client library:

The DefaultAzureCredential is the most straightforward approach and uses the environment variables injected by the Azure Workload Identity mutating webhook to authenticate with Azure Key Vault.

Azure AD Workload Identity is a game-changer for developers. It allows software workloads running outside of Azure to authenticate to Entra-protected resources without the need to maintain secrets or certificates. This is achieved through workload identity federation, which configures a trust relationship between your user-assigned managed identity or app registration in Microsoft Entra ID and the external IdP of the platform you wish to trust.

You can use user-assigned identities or app registrations to authenticate software workloads to Entra ID, even when running outside of Azure. This eliminates the need to store and manage client IDs and secrets/certificates, which is error-prone and riskier from a security standpoint.

For workload identity federation to work, you need to configure a trust relationship between your user-assigned managed identity or app registration in Microsoft Entra ID and the external IdP of the platform you wish to trust. This involves setting up a webhook that injects environment variables, such as the client ID from the annotation on service accounts, to determine which identity to get a token for.

To authenticate workloads to Entra ID, you can use the Azure Identity client libraries, which provide different approaches for getting tokens. These include using DefaultAzureCredential, creating a ChainedTokenCredential instance, or using WorkloadIdentityCredential directly.

Here are the minimum package versions required for each language ecosystem's client library:

With Azure AD Workload Identity, you can eliminate the maintenance burden of manually managing credentials and eliminate the risk of leaking secrets or having certificates expire. It's a powerful tool for developers to authenticate software workloads to Entra-protected resources without the need for manual configuration or management.

Azure Workload Identity is a game-changer for developers and ops teams alike. It allows you to authenticate software workloads to Entra ID without the need to maintain secrets or certificates. This is made possible by Workload Identity Federation, which enables trust relationships between your user-assigned managed identity or app registration and the external IdP of the platform you wish to trust.

You can use user-assigned identities or app registrations to authenticate software workloads to Entra ID, even when running outside of Azure. This is a huge flexibility boost for developers, as they can execute scripts without being connected to an Azure-hosted virtual machine, scale set, function app, etc.

Managed identities (MI) are the preferred method for allowing applications to connect to resources that support Microsoft Entra authentication. They are typically recommended over other mechanisms, such as Applications, because they are automatically managed by Entra ID, eliminating the need for ops teams to store and rotate credential secrets.

There are two types of managed identities: System-assigned MI and User-assigned MI. Using a managed identity is straightforward, and you can trigger a request to a predefined endpoint to acquire an access token for the desired resource.

Here are the differences between the two types of managed identities:

App Services, Azure Functions, and Container Apps use a different endpoint to acquire an access token, which can be obtained from the IDENTITY_ENDPOINT environment variable. It's also recommended to use the IDENTITY_HEADER to prevent server-side request forgery (SSRF) attacks.

When creating federated identity credentials, it's essential to be aware of the limitations. You can have a maximum of 20 federated identity credentials per managed identity.

Creation of federated identity credentials is not supported on user-assigned managed identities in certain regions. For the updated list of unsupported regions, check the Microsoft documents page.

Federated tokens need to be signed with the RS256 algorithm. This is a specific requirement for federated tokens to work correctly.

To avoid timing issues, it's a good idea to introduce a delay of about a minute between creating the credential and using it. This can help prevent failures due to propagation delays.

Here are some key limitations to keep in mind:

To enable workload identity federation on your Kubernetes cluster, you can create an AKS cluster with federation and the mutating webhook. This will give you the issuer URL, which you'll need to configure your federated credential on your user-assigned managed identity.

For applications using workload identity, it's required to add the label azure.workload.identity/use: "true" to the pod spec. This label is necessary for AKS to move workload identity to a Fail Close scenario, providing a consistent and reliable behavior for pods that need to use workload identity.

Here's a list of required and recommended labels and annotations for pod configuration:

You can use the Azure CLI to configure the federated credential on your managed identity, or you can use the Azure portal to achieve the same outcome.

Migrating to Microsoft Entra can be a straightforward process. You can configure a pod-managed identity to use workload identity one of two ways. The first option allows you to use the same configuration you've implemented for pod-managed identity.

To enable Microsoft Entra Workload ID, you can annotate the service account within the namespace with the identity. This annotation injects the identity into the pods.

The second option is to rewrite your application to use the latest version of the Azure Identity client library. This is a more permanent solution, but it requires more effort.

We've developed a migration sidecar that converts IMDS transactions to OpenID Connect (OIDC). This sidecar is a temporary solution to help you get up and running quickly on workload identity.

The following table summarizes our migration or deployment recommendations for workload identity:

Using the migration sidecar or updating the Azure Identity client library will help you migrate to Microsoft Entra Workload ID. By doing so, you'll be able to use workload identity federation to access Microsoft Entra protected resources.

Microsoft Entra ID issued tokens may not be used for federated identity flows. This means you can't use tokens from Microsoft Entra ID for federated identity flows.

You can use workload identity federation to access Microsoft Entra protected resources from various platforms, including Kubernetes clusters, GitHub Actions, Google Cloud, and Amazon Web Services (AWS).

Here are some of the supported scenarios:

A self-signed DIY solution can be created in a matter of minutes using a tool like OpenSSL.

You'll need to generate a private key and a certificate signing request, which can be done with just a few commands.

The private key is used to sign the certificate, and it's also used to encrypt data.

For example, the OpenSSL command `openssl req -newkey rsa:2048 -nodes -keyout key.pem -out csr.pem` generates a private key and a certificate signing request.

In this case, the private key is saved to a file called key.pem.

This method is often used for development purposes, and it's not recommended for production use due to security concerns.

A self-signed certificate is created by signing the certificate signing request with the private key.

For example, the OpenSSL command `openssl x509 -req -in csr.pem -signkey key.pem -out cert.pem` creates a self-signed certificate.

This certificate can be used for testing purposes, but it's not trusted by default by most browsers and applications.

In various scenarios, Microsoft Entra ID can be used to access protected resources. Workloads running on any Kubernetes cluster can establish a trust relationship with Microsoft Entra ID.

Azure Kubernetes Service (AKS), Amazon Web Services EKS, Google Kubernetes Engine (GKE), or on-premises clusters are all supported. You can also use workload identity federation with on-premises Kubernetes clusters.

GitHub Actions can be configured to use Microsoft Entra ID. This involves setting up a trust relationship between Microsoft Entra ID and a GitHub repo, and then configuring a GitHub Actions workflow to get an access token from Microsoft identity provider.

Google Cloud and Amazon Web Services (AWS) are also supported. To use Microsoft Entra ID with these platforms, you need to configure a trust relationship between Microsoft Entra ID and an identity in the respective cloud provider.

Here are some specific supported scenarios:

Microsoft Entra ID issued tokens may not be used for federated identity flows. The federated identity credentials flow does not support tokens issued by Microsoft Entra ID.