Edit

Share via

Workload identity federation

  • Article

This article provides an overview of workload identity federation for software workloads. Using workload identity federation allows you to access Microsoft Entra protected resources without needing to manage secrets (for supported scenarios).

You can use workload identity federation in scenarios such as GitHub Actions, workloads running on Kubernetes, or workloads running in compute platforms outside of Azure.

Why use workload identity federation?

Watch this video to learn why you would use workload identity federation.

Typically, a software workload (such as an application, service, script, or container-based application) needs an identity in order to authenticate and access resources or communicate with other services. When these workloads run on Azure, you can use managed identities and the Azure platform manages the credentials for you. For a software workload running outside of Azure, or those running in Azure but use app registrations for their identities, you need to use application credentials (a secret or certificate) to access Microsoft Entra protected resources (such as Azure, Microsoft Graph, Microsoft 365, or third-party resources). These credentials pose a security risk and have to be stored securely and rotated regularly. You also run the risk of service downtime if the credentials expire.

You use workload identity federation to configure a user-assigned managed identity or app registration in Microsoft Entra ID to trust tokens from an external identity provider (IdP), such as GitHub or Google. The user-assigned managed identity or app registration in Microsoft Entra ID becomes an identity for software workloads running, for example, in on-premises Kubernetes or GitHub Actions workflows. Once that trust relationship is created, your external software workload exchanges trusted tokens from the external IdP for access tokens from Microsoft identity platform. Your software workload uses that access token to access the Microsoft Entra protected resources to which the workload has been granted access. You eliminate the maintenance burden of manually managing credentials and eliminates the risk of leaking secrets or having certificates expire.

Supported scenarios

The following scenarios are supported for accessing Microsoft Entra protected resources using workload identity federation:

  • Workloads running on any Kubernetes cluster (Azure Kubernetes Service (AKS), Amazon Web Services EKS, Google Kubernetes Engine (GKE), or on-premises). Establish a trust relationship between your user-assigned managed identity or app in Microsoft Entra ID and a Kubernetes workload (described in the workload identity overview).
  • GitHub Actions. First, configure a trust relationship between your user-assigned managed identity or application in Microsoft Entra ID and a GitHub repo in the Microsoft Entra admin center or using Microsoft Graph. Then configure a GitHub Actions workflow to get an access token from Microsoft identity provider and access Azure resources.
  • Workloads running on Azure compute platforms using app identities. First assign a user-assigned managed identity to your Azure VM or App Service. Then, configure a trust relationship between your app and the user-assigned identity.
  • Google Cloud. First, configure a trust relationship between your user-assigned managed identity or app in Microsoft Entra ID and an identity in Google Cloud. Then configure your software workload running in Google Cloud to get an access token from Microsoft identity provider and access Microsoft Entra protected resources. See Access Microsoft Entra protected resources from an app in Google Cloud.
  • Workloads running in Amazon Web Services (AWS). First, configure a trust relationship between your user-assigned managed identity or app in Microsoft Entra ID and an identity in Amazon Cognito. Then configure your software workload running in AWS to get an access token from Microsoft identity provider and access Microsoft Entra protected resources. See Workload identity federation with AWS.
  • Other workloads running in compute platforms outside of Azure. Configure a trust relationship between your user-assigned managed identity or application in Microsoft Entra ID and the external IdP for your compute platform. You can use tokens issued by that platform to authenticate with Microsoft identity platform and call APIs in the Microsoft ecosystem. Use the client credentials flow to get an access token from Microsoft identity platform, passing in the identity provider's JWT instead of creating one yourself using a stored certificate.
  • SPIFFE and SPIRE are a set of platform agnostic, open-source standards for providing identities to your software workloads deployed across platforms and cloud vendors. First, configure a trust relationship between your user-assigned managed identity or app in Microsoft Entra ID and a SPIFFE ID for an external workload. Then configure your external software workload to get an access token from Microsoft identity provider and access Microsoft Entra protected resources. See Workload identity federation with SPIFFE and SPIRE.
  • Create a new service connection in Azure Pipelines (preview). Create an Azure Resource Manager service connection using workload identity federation.

Note

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.

How it works

Create a trust relationship between the external IdP and a user-assigned managed identity or application in Microsoft Entra ID. The federated identity credential is used to indicate which token from the external IdP should be trusted by your application or managed identity. You configure a federated identity either:

Note

The Federated Identity Credential issuer, subject, and audience values must case-sensitively match the corresponding issuer, subject and audience values contained in the token being sent to Microsoft Entra ID by the external IdP in order for the scenario to be authorized. For more information surrounding this change, please visit What's new for Authentication.

The workflow for exchanging an external token for an access token is the same, however, for all scenarios. The following diagram shows the general workflow of a workload exchanging an external token for an access token and then accessing Microsoft Entra protected resources.

Diagram showing an external token exchanged for an access token and accessing Azure

  1. The external workload (such as a GitHub Actions workflow) requests a token from the external IdP (such as GitHub).
  2. The external IdP issues a token to the external workload.
  3. The external workload (the sign in action in a GitHub workflow, for example) sends the token to Microsoft identity platform and requests an access token.
  4. 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.
  5. When the checks are satisfied, Microsoft identity platform issues an access token to the external workload.
  6. 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.

The Microsoft identity platform stores only the first 100 signing keys when they're downloaded from the external IdP's OIDC endpoint. If the external IdP exposes more than 100 signing keys, you may experience errors when using workload identity federation.

See also