Federating AKS workload identity step by step guide

This is a step by step guide to show how we can federate our workload identity in a kubernetes cluster.

First we enable OIDC on our cluster. Next, we create a managed identity in Azure. 

Then we will be creating a service account and the federating the managed identity.

# 1. Enable OIDC and Workload Identity on your cluster

az aks update -g myRG -n myCluster --enable-oidc-issuer --enable-workload-identity

# 2. Get the OIDC Issuer URL (needed for the trust)

AKS_OIDC_ISSUER=$(az aks show -n myCluster -g myRG --query

"oidcIssuerProfile.issuerUrl" -otsv)

# 3. Create the Managed Identity in Azure

az identity create --name "my-app-identity" --resource-group myRG

# 4. Create the Kubernetes Service Account (SA)

# Note: You MUST annotate it with the Client ID of the Managed Identity

CLIENT_ID=$(az identity show --name "my-app-identity"

--resource-group myRG --query clientId -o tsv)

kubectl create serviceaccount my-app-sa

kubectl annotate serviceaccount my-app-sa

azure.workload.identity/client-id=$CLIENT_ID

# 5. FEDERATE: Create the trust between the SA and the Managed Identity

az identity federated-credential create \

  --name "my-federated-id" \

  --identity-name "my-app-identity" \

  --resource-group myRG \

  --issuer "$AKS_OIDC_ISSUER" \

  --subject "system:serviceaccount:default:my-app-sa"

So what really going on behind the scheme here when we are trying to access an Azure resources.

The Pod Requests a Token: When your app starts, a "mutating webhook" in AKS has already injected a projected volume into your Pod. This volume contains a Kubernetes Service Account Token.

The Exchange: Your app (using the Azure Identity SDK) takes that K8s token and sends it to the Microsoft Entra ID (Azure AD) token endpoint.

The Validation: Entra ID sees the token. Because of the Federated Credential you created, Entra ID knows to go to your AKS Cluster's OIDC Endpoint to verify the signature of that token.

The Azure Token: Once Entra ID confirms the K8s token is valid and matches the "Subject" (Namespace + SA Name), it exchanges it for a real Azure Access Token.

Access Resource: Your app now uses that Azure Access Token to talk to Key Vault, Storage, or SQL.