Migrating AKS workloads from AAD Pod Identity to Entra Workload ID
You're looking at an AKS cluster for a client. Somewhere in it, a pod is authenticating to Azure using AAD Pod Identity. It relies on AzureIdentity and AzureIdentityBinding custom resources. It depends on the Node Managed Identity (NMI) pods intercepting metadata requests on port 2579. It is deprecated. Microsoft pulled the plug a year ago. The NMI intercept is a tax on the cluster's CPU and a liability in the threat model. You need to move it to Entra Workload ID. It uses OIDC federation. It is cleaner. But cleaner does not mean easy. Inventory the plumbing Do not just generate new manifests and hope for the best. Inventory what you actually have. Every AzureIdentityBinding is a dependency. Every AzureIdentity is a managed identity mapped to a specific set of pod labels. Map each workload to its intended federated Kubernetes Service Account. If you do not know exactly what the old identity does, you will not know what permissions the new one needs. Treat the ol
You're looking at an AKS cluster for a client.
Somewhere in it, a pod is authenticating to Azure using AAD Pod Identity. It relies on AzureIdentity and AzureIdentityBinding custom resources. It depends on the Node Managed Identity (NMI) pods intercepting metadata requests on port 2579.
It is deprecated. Microsoft pulled the plug a year ago. The NMI intercept is a tax on the cluster's CPU and a liability in the threat model.
You need to move it to Entra Workload ID. It uses OIDC federation. It is cleaner. But cleaner does not mean easy.
Inventory the plumbing
Do not just generate new manifests and hope for the best.
Inventory what you actually have. Every AzureIdentityBinding is a dependency. Every AzureIdentity is a managed identity mapped to a specific set of pod labels.
Map each workload to its intended federated Kubernetes Service Account. If you do not know exactly what the old identity does, you will not know what permissions the new one needs.
Treat the old bindings as a map of your actual access patterns, not just a list of resources to delete.
Validate the exact strings
Entra Workload ID does not guess. It matches strings.
When you create the federated identity credential in Entra ID, the issuer is your AKS OIDC endpoint. The subject must be exactly system:serviceaccount:.
Miss a colon. Add a trailing space. Use the wrong namespace. It will not give you a helpful error. It will just give you a 401 Unauthorized.
The pod also requires the label azure.workload.identity/use: "true". Without it, the Entra workload identity mutating webhook ignores the pod. No environment variables get injected. No service account token gets projected. The pod starts, but it cannot authenticate.
Test the token exchange before you move production traffic.
Exec into a debug pod. Request the token from the projected volume. Decode it. Check the aud (audience) and sub (subject) claims. Verify the exact string matches what you configured in Entra ID.
Stage the migration
Do not do a cutover. Do a migration.
Deploy the new service account and the federated identity credential. Update the workload definition to use the new service account and apply the required pod label.
Watch the logs. Verify the token exchange succeeds.
Once the new identity is serving traffic and passing health checks, kill the old AzureIdentityBinding and AzureIdentity resources.
Do not leave the old plumbing in the cluster "just in case." Deprecated resources left behind become permanent attack surface. If you do not need it, delete it.
Prove it works
You are not done when the pod starts. You are done when you prove it can do its job.
Check the Azure Activity Log. Look for the API calls.
See the new managed identity making the requests. See the old one go silent.
That is the only evidence that matters. The new identity reaches the required services with the intended permissions, and the old plumbing is gone.
