Meteen naar de inhoud

Workload Identity Federation

  • door

Supported scenarios

repo: https://github.com/arindam0310018/10-Oct-2023-DevOps__Workload-Identity-Federation-with-Service-Principal-Using-Terraform/blob/main/az-workload-identity-federation.tf

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.
  • 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.

 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:

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 login 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.

Next steps

Learn more about how workload identity federation works:

  • How to create, delete, get, or update federated identity credentials on a user-assigned managed identity.
  • How to create, delete, get, or update federated identity credentials on an app registration.
  • Read the workload identity overview to learn how to configure a Kubernetes workload to get an access token from Microsoft identity provider and access Microsoft Entra protected resources.
  • Read the GitHub Actions documentation to learn more about configuring your GitHub Actions workflow to get an access token from Microsoft identity provider and access Microsoft Entra protected resources.
  • How Microsoft Entra ID uses the OAuth 2.0 client credentials grant and a client assertion issued by another IdP to get a token.
  • For information about the required format of JWTs created by external identity providers, read about the assertion format.