Modern authentication with Azure workload identity federation

Introduction:

Workload identity federation provides secure access to Azure resources from outside systems such as GitHub Actions, Azure DevOps, and Kubernetes without secret management. It utilizes Microsoft Entra ID for a trust-based token exchange, increasing security and making CI/CD flows easier.

Problem Statement:

An application service or script running outside of azure uses a secret or certificate to access protected resources in azure, Microsoft graph. Secrets and certificates pose a security risk and can also expire which leads to service downtime.

Solution Approach:

Workload identity federation enables you to access the Microsoft Entra ID, Entra id protected resources without having to handle secrets. You can set up an app registration in Entra ID to trust an external identity provider like GitHub, google cloud or Kubernetes so your external software is able to access the resources to which the app registration has been provisioned access

How it works:

To enable external workloads (such as GitHub Actions) to use Entra ID protected resources without handling secrets, you can set up a federated identity credential using either:

• User-assigned managed identity
• App registration

A Federated Identity Credential is what associates an external identity provider (IdP) token with a managed identity or application in Microsoft Entra ID. The credential setup involves the issuer, subject, and audience of the token, and all of these should match exactly, including case, in order for the authorization to proceed. After the trust relationship has been established, external tokens can be exchanged for Entra ID access tokens in a smooth process, using a standard workflow for various scenarios.

Token Exchange Workflow:

• External workload (e.g., GitHub Actions) solicits a token from its IdP.
• IdP provides the token to the workload.
• Workload passes the token to Microsoft identity platform in order to obtain an access token.
• Microsoft checks the external token against the set trust configuration.
• On successful verification, Microsoft provides an access token.
• The workload utilizes the access token to access Microsoft  protected resources (such as Azure App Service).
  

  Token Exchange

Use Case: GitHub Actions with Federated Credentials
Through federation, GitHub Actions can securely use Azure resources without keeping secrets. Federated tokens with az login are used by workflows for secure Azure deployments, making CI/CD easier and more secure.

• To configure a federated identity for GitHub Actions with an App Registration in  Entra ID
• Navigate to App registrations within the Entra ID and choose your application.
• From the menu on the left, go to Certificates & secrets, open the Federated credentials tab, and click Add credential.
• Within the Federated credential scenario dropdown, choose GitHub Actions deploying Azure resources.
• Input your GitHub organization and repository that the workflow is defined in.
• For Entity type, select Environment, Branch, Pull request, or Tag, and enter the value for the same. These values should exactly match the ones defined in your GitHub workflow.
  Note: Pattern matching is not supported for branches and tags, so use an environment name when specifying multiple branches or tags.
• Provide a Name for the federated credential.
• The Issuer, Audience, and Subject fields will automatically populate based on your input.
• Click Add to complete the configuration.
  

  github-action Federated Credentials

• After configuring the federated identity, you’ll need to reference the following values from your app registration in your GitHub Actions workflow:
  AZURE_CLIENT_ID: The Application (client) ID of your  app.
  AZURE_TENANT_ID & AZURE_SUBSCRIPTION_ID: The Directory (tenant) & Subscription ID for your Azure Account.
  

  github

• After that you can test the Federated Credentials using the workflow below.

Use Case: Azure DevOps with Federated Credentials
Azure DevOps now utilizes a workload identity federation process to obtain tokens from  Entra ID that pipeline can use directly to authenticate with an OpenID Connect (OIDC) token in order to access Azure resources securely.
When setting up federated credentials for Azure DevOps, there are two principal setup methods, depending on your level of access and your control needs:

Automatic Configuration:
This method is most suitable when your Azure DevOps setup has the necessary permissions to create or update app registrations and federated credentials automatically. Azure DevOps sets it up behind the scenes as part of creating the service connection.

• • Open your Azure DevOps project and navigate to Project Settings.
  • In Pipelines, choose Service Connections and click New service connection.
  • Select Azure Resource Manager as the connection type.
  • Set Identity type to App registration (automatic).
  • Select Workload identity federation as the credential method.
  • Select the correct scope: Subscription, Management Group, or Machine Learning Workspace.
  • Select your Azure subscription and optionally select a resource group.
  • Enter a Service Connection Name and optional Service Management Reference.
  • Click Save to allow Azure DevOps to automatically complete app registration and federated credential configuration.
    

    Automatic Service Connection

Manual Configuration:
Choose this approach if granular management of how the app registration or managed identity is created and secured is needed. This is ideal for organizations with stringent governance policies or that want to control identity assignment and federated trust relationships by hand.
For manual setup use following steps:

• Create a user-assigned managed identity or app registration in Azure.
• In Azure DevOps, create a service connection type Azure Resource Manager.
  

  Manual Service Connection

• Use existing app registration/client information and subscription details.
  

  Manual Service Connection

  

  Manual Service Connection

• Mark the Issuer URL and Subject Identifier from Azure DevOps configuration.
  Set these up in Federated Credentials:
  For app registration: navigate to Certificates & Secrets > Federated Credentials.
  For managed identity: navigate to Federated Credentials blade.
  

  Federated Credentials

Assign the required roles (e.g., Contributor or Reader) to the app registration or managed identity at the specified scope. Finally, verify the service connection using a test pipeline to ensure Azure access.

Use Case: Kubernetes with Federated Credentials
Federated identity allows Kubernetes workloads (AKS, EKS, GKE, or self-managed clusters) to securely access Azure services such as Blob Storage, Postgres  or Key Vault by trading tokens through Entra ID—there’s no requirement to have secrets stored in pods.

• To support Kubernetes workload identity in Azure Kubernetes Service, both the OIDC issuer and workload identity capabilities must be enabled. You can do this when creating a cluster or upgrade an existing one with the following flags via the Azure CLI: –enable-oidc-issuer and –enable-workload-identity.
• After enabling, get the OIDC issuer URL by executing the command below. This should be used when configuring federated credentials in Microsoft Entra ID
  

  export AKS_OIDC_ISSUER=”$(az aks show –name “${CLUSTER_NAME}” \ –resource-group “${RESOURCE_GROUP}” \ –query “oidcIssuerProfile.issuerUrl” \ –output tsv)”

• Create a Kubernetes service account and annotate it with the client ID of the existing or newly created managed identity/app registration
  

  export SERVICE_ACCOUNT_NAMESPACE=”default” export SERVICE_ACCOUNT_NAME=”workload-identity-sa$RANDOM_ID” cat <<EOF | kubectl apply -f – apiVersion: v1 kind: ServiceAccount metadata: annotations: azure.workload.identity/client-id: “${USER_ASSIGNED_CLIENT_ID}” name: “${SERVICE_ACCOUNT_NAME}” namespace: “${SERVICE_ACCOUNT_NAMESPACE}” EOF

• Add Cluster Issuer URL, namespace, Service Account into your app registration/ managed identity under federated credential session.
  

  Federated Credentials for kubernetes

• Once deploying your application pods, make sure they are pointing to the right Kubernetes service account by specifying the namespace and the serviceAccountName in the pod manifest.
• Below is a sample manifest to fetch a secret from Azure Key Vault using workload identity. And before that assign the Key Vault Secrets Officer role to the associated managed identity or app registration to allow access to secrets.
  

  kubectl apply -f – <<EOF apiVersion: v1 kind: Pod metadata: name: sample-workload-identity-key-vault namespace: ${SERVICE_ACCOUNT_NAMESPACE} labels: azure.workload.identity/use: “true” spec: serviceAccountName: ${SERVICE_ACCOUNT_NAME} containers:Credentials – image: ghcr.io/azure/azure-workload-identity/msal-go name: oidc env: – name: KEYVAULT_URL value: ${KEYVAULT_URL} – name: SECRET_NAME value: ${KEYVAULT_SECRET_NAME} nodeSelector: kubernetes.io/os: linux EOF

Limitations:-

• There is a limit of 20 federated identity credentials per app registration or user-assigned managed identity. This limits the number of distinct trust configurations you can have per identity, which can be a choke point for intricate multi-environment or multi-provider use cases.
• Microsoft Entra ID has a strict, case-sensitive match between the issuer, subject, and audience of the token and the equivalent values set in the federated credential. Mismatch causes rejection of the token, so exactness in configuration is crucial. If you wish to bypass with Strict Token Matching limitation use flexible federated identity but it is public preview

Conclusion:-

Federating identity with Azure services provides a secure and efficient means to authenticate without secrets or credentials. Using either a user-assigned managed identity or an app registration, workload identity federation configuration allows your CI/CD pipelines—such as those in GitHub Actions or Azure DevOps—to securely access Azure resources. By establishing the trust relationship correctly and filling in the proper roles, you can have a more sustainable, scalable, and secure deployment process that conforms to current cloud security standards