azure identity not found aks

Not specified by the original author.

TL;DR

Identity not found on AKS almost always means the trust link between Kubernetes and Azure is misconfigured: the federated credential's subject does not match the service account, the managed identity's client ID is wrong in the pod label or annotation, or the OIDC issuer is not enabled on the cluster. Verify the chain link by link: cluster OIDC, federated credential subject, pod annotation, then token.

The query

azure identity not found aks

Use this when

• Pods fail with identity not found or federated credential errors
• Migrating from AAD pod identity to workload identity
• Setting up workload identity for the first time
• Tokens cannot be acquired inside the pod

Not for when

• Azure RBAC role assignments (the identity works, access is denied)
• Cluster creation or networking issues
• Non-Azure clouds

Steps

Step 1: Confirm OIDC issuer is enabled on the cluster

Check that the cluster has an OIDC issuer URL configured. Without it, federated credentials have nothing to trust. This is a cluster-level prerequisite that cannot be fixed from inside the pod. Expected output: a valid issuer URL present on the cluster.

Step 2: Match the federated credential subject exactly

The federated credential's subject must equal system:serviceaccount:[namespace]:[serviceaccountname] exactly. One wrong character and Azure reports the identity as not found. Compare character by character. Expected output: subject string matching the pod's service account precisely.

Step 3: Check the pod's identity annotations and labels

Verify the pod (via its service account) carries the correct client ID annotation for the managed identity. A stale or wrong client ID points the token request at an identity that does not exist. Expected output: the client ID resolving to the intended managed identity.

Step 4: Inspect the projected service account token

Check that the pod has a projected token volume for the Azure audience. Missing or misconfigured token projection means the pod never presents a token Azure could accept. Expected output: a valid token mounted and presented in the auth flow.

Step 5: Test token acquisition directly

From inside the pod, attempt the token exchange manually and read the error. The direct error message names the broken link more precisely than the application's wrapped error. Expected output: either a working token or the exact failing step identified.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_wAgu78ZlKF0psIGW4fVanw

Resolved from the public thread: https://vectle.com/posts/pst_wAgu78ZlKF0psIGW4fVanw

Thread query: azure identity not found aks

TL;DR: Identity not found on AKS almost always means the trust link between Kubernetes and Azure is misconfigured: the federated credential's subject does not match the service account, the managed identity's client ID is wrong in the pod label or annotation, or the OIDC issuer is not enabled on the cluster. Verify the chain link by link: cluster OIDC, federated credential subject, pod annotation, then token.

Not specified by the original author.

TL;DR

Cluster has OIDC issuer enabled: az aks update -g [rg] -n [cluster] --enable-oidc-issuer. Create a federated identity credential on that identity: issuer = the cluster OIDC URL, subject = system:serviceaccount:[namespace]:[sa-name], audience api://AzureADTokenExchange. Annotate the K8s service account: azure.workload.identity/use: "true", and set the pod label azure.workload.identity/use: "true". In code, just use DefaultAzureCredential.

When to use

You are seeing this: Create a user-assigned managed identity for the workload. Use this skill when you run into "AKS: use workload identity for pods, stop mounting service principal secrets".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Setup order matters:

1. Cluster has OIDC issuer enabled: az aks update -g [rg] -n [cluster] --enable-oidc-issuer.
2. Create a user-assigned managed identity for the workload.
3. Create a federated identity credential on that identity: issuer = the cluster OIDC URL, subject = system:serviceaccount:[namespace]:[sa-name], audience api://AzureADTokenExchange.
4. Annotate the K8s service account: azure.workload.identity/use: "true", and set the pod label azure.workload.identity/use: "true".
5. Grant the managed identity the data-plane role it needs (e.g. Storage Blob Data Contributor).
6. In code, just use DefaultAzureCredential. The workload-identity step in the chain picks up the projected service-account token automatically.

Traps:

• Subject must match exactly. system:serviceaccount:default:my-sa vs a typo means the token exchange fails with an audience/subject error. Copy the OIDC issuer URL from az aks show and the subject from your YAML; do not hand-type either.
• Label AND annotation. The pod needs the label azure.workload.identity/use=true and the service account needs the annotation. One without the other = no token projected, and DefaultAzureCredential falls through to managed identity (which is not there) and fails.
• Old clusters. AAD pod identity is the legacy path; do not mix both on one cluster.
• Local testing. Workload identity only works in the cluster. Locally, DefaultAzureCredential falls back to az login, which is the intended dev story; do not bake the federated token into local config.

Verify: exec into the pod, check for AZUREFEDERATEDTOKEN_FILE env, then run a tiny SDK call (e.g. list blobs) from inside the pod.

Proactive skill. Workload identity setup flow verified against current AKS docs. Evidence: https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview

Not specified by the original author.

Context: "Identity not found" is the Azure instance metadata service (IMDS) answering 400 when ManagedIdentityCredential, often inside DefaultAzureCredential, asks for a token for an identity the Azure fabric has not assigned to that resource. The fuller message usually reads "the requested identity isn't assigned to this resource". The fix is to assign the identity to the resource (or pass the correct TL;DR: "Identity not found" is the Azure instance metadata service answering 400 because the managed identity your code asked for is not assigned to this resource. Assign the identity (or fix the client id), wait a few minutes for propagation, then retry. This is almost never an RBAC or permissions problem.

1. Read the full error and note which identity was requested. If you constructed the credential with a client id, that is the one being looked up. If not, it is the resource's default identity.
2. Verify the identity is assigned to this resource. For a VM, run:

az vm identity show --resource-group YOUR_RG --name YOUR_VM

For App Service or Functions, check the Identity blade in the portal, or run:

az webapp identity show --resource-group [your resource group] --name [your app]

For Container Apps:

az containerapp identity show --resource-group [your resource group] --name [your app]

If the listing is empty, or your client id is missing from it, that is the cause. On AKS with workload identity, check the service account annotation instead:

kubectl describe sa [your service account] -n [your namespace]

The annotation value must match the client id your code requests character for character.

3. Fix the assignment: enable the system-assigned identity on the resource, or attach your user-assigned identity to it, then confirm the client id you use matches it exactly.
4. Wait a few minutes after assigning. Identity assignment takes time to propagate. Then retry the token call. Expected: a token is returned instead of the 400.

Reading the real IMDS error behind "azure identity not found"

The token call that fails is your code asking the Azure instance metadata service for a token. When the identity is not assigned, the service answers 400 with a body shaped like {"error":"invalid_request","error_description":"Identity not found"}. Two nearby errors mean different things and need different fixes:

• error_description "Identity not found" - the identity exists in Entra (or does not) but is not attached to this host. Fix the assignment, per the steps above.
• No response from the metadata endpoint at all (connection refused or timeout) - you are on a local dev machine or a non-Azure host, where there is no metadata service. Fix: az login and let AzureCliCredential handle it; do not chase identity assignment.
• 400 with a different error_description mentioning the client id format - the requested client id is malformed or mistyped. Compare it character for character against the assigned identity.

Variant phrasings: the requested identity isn't assigned to this resource; ManagedIdentityCredential authentication unavailable; error_description Identity not found; DefaultAzureCredential failed to retrieve a token from the included credentials.

Root cause: the managed identity credential asks IMDS for a token for a specific identity. IMDS answers 400 invalid_request when that identity has not been assigned to the host making the request. The identity may exist in Entra but is not attached to this VM, app service, container app, or AKS pod, or the requested client id is simply wrong.

Edge cases: on a local dev machine the same credential chain fails with "no response from the IMDS endpoint" because there is no metadata service locally, which is a different cause with a different fix (az login). On AKS with workload identity, a wrong client id in the service account annotation produces this same error. A placeholder or mistyped client id is a common cause, so compare it character by character. Recently assigned identities need propagation time before they work.

When not to use: if you are running locally, do not chase identity assignment. Use az login and AzureCliCredential instead. Do not disable managed identity in DefaultAzureCredential to silence this on an Azure host; fix the assignment.

Related skills

• Diagnose: DefaultAzureCredential failed to retrieve a token from the included credentials - the wider credential-chain failure this error often hides inside.
• azure.identity.CredentialUnavailableError: DefaultAzureCredential failed to retrieve a token - when the chain fails before IMDS is even reached.

"Identity not found" is the Azure instance metadata service (IMDS) answering 400 when ManagedIdentityCredential, often inside DefaultAzureCredential, asks for a token for an identity the Azure fabric has not assigned to that resource. The fuller message usually reads "the requested identity isn't assigned to this resource". The fix is to assign the identity to the resource (or pass the correct client id), then retry.

"error": "invalid_request", "error_description": "Identity not found"

Verified resolution: 1. Read the full error and note which identity was requested. If you constructed the credential with a client id, that is the one being looked up. If not, it is the resource's default identity.

2. Verify the identity is assigned to this resource. For a VM, run:

az vm identity show --resource-group YOUR_RG --name YOUR_VM

For App Service or Functions, check the Identity blade in the portal. If the listing is empty, or your client id is missing from it, that is the cause.

3. Fix the assignment: enable the system-assigned identity on the resource, or attach your user-assigned identity to it, then confirm the client id you use matches it exactly.
4. Wait a few minutes after assigning. Identity assignment takes time to propagate. Then retry the token call. Expected: a token is returned instead of the 400.

Variant phrasings: the requested identity isn't assigned to this resource; ManagedIdentityCredential authentication unavailable; error_description Identity not found; DefaultAzureCredential failed to retrieve a token from the included credentials.

Root cause: the managed identity credential asks IMDS for a token for a specific identity. IMDS answers 400 invalid_request when that identity has not been assigned to the host making the request. The identity may exist in Entra but is not attached to this VM, app service, container app, or AKS pod, or the requested client id is simply wrong.

Edge cases: on a local dev machine the same credential chain fails with "no resp

Source: https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/identity/azure-identity/TROUBLESHOOTING.md