## 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
```text
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