AKS Workload Identity for Azure AI Services

Why Workload Identity on AKS

The old approach to pod-level Azure authentication was AAD Pod Identity. It relied on CRDs, NMI daemonsets running on every node, and a fair amount of YAML plumbing. It worked, but it was complex to operate and had known security limitations. Microsoft deprecated it in favor of a cleaner model.

AKS Workload Identity (GA since May 2023) replaces all of that with Kubernetes service account token federation against Entra ID. No daemonsets, no CRDs, no NMI pods intercepting traffic. Your pod gets an Entra ID token projected by Kubernetes itself, and Azure accepts it directly. The result is a simpler architecture with a better security model.

How It Works

Three things connect to make this work:

A Kubernetes service account annotated with the managed identity's client ID
A user-assigned managed identity in Azure with a federated credential that trusts that specific service account
RBAC role assignments on the target Azure resources (in this case, Azure OpenAI)

When a pod runs with that service account, Kubernetes projects a signed token into the pod. The Azure Identity SDK exchanges that token for an Entra ID access token via the federated credential trust. DefaultAzureCredential picks this up automatically, so your application code doesn't need any special handling.

Terraform: AKS Cluster with Workload Identity

The two key settings on the AKS cluster are oidc_issuer_enabled and workload_identity_enabled. The OIDC issuer exposes a discovery endpoint that Azure uses to validate tokens from the cluster.

Terraform: Managed Identity and Federated Credential

Next, create a user-assigned managed identity, a federated credential linking it to the Kubernetes service account, and a role assignment granting it access to Azure OpenAI.

The subject field follows the format system:serviceaccount:<namespace>:<service-account-name>. This is how Azure knows which Kubernetes service account is allowed to request tokens for this managed identity.

Kubernetes: Service Account and Pod

On the Kubernetes side, the service account needs two things: an annotation with the managed identity's client ID, and a label telling the webhook to inject the projected token volume.

Notice there are no secrets, no key vaults, and no API keys anywhere in the deployment. The workload identity webhook automatically mounts the projected service account token and sets the required environment variables for the Azure Identity SDK.

Application Code: Python with DefaultAzureCredential

The application code is straightforward. DefaultAzureCredential automatically detects the workload identity environment and acquires a token for Azure Cognitive Services.

This same code works unchanged in local development (where DefaultAzureCredential falls through to Azure CLI or VS Code credentials) and in production on AKS (where it picks up the projected token). No code changes needed between environments.

Verifying the Setup

After deploying, verify the pieces are connected correctly.

If the OIDC issuer URL is empty, workload identity isn't enabled on the cluster. If the federated credential list is empty, the trust relationship hasn't been established. Check the pod logs for authentication errors; the Azure Identity SDK provides clear error messages when the token exchange fails.

AKS Workload Identity: Authenticate Pods to Azure AI Services Without Secrets