prod-auth-triage

Check the istio-proxy sidecar access logs, not app logs, since most apps log no HTTP requests. Then verify whether the Entra app registration was recreated by comparing Secrets Manager CreatedDate and LastChangedDate, which indicates a new client ID broke all consumers.

IDX10214 occurs when the token's audience does not match the API's expected client ID, typically because the API's app registration was destroyed and recreated with a new client ID. Consumers still hold the stale ID, so their tokens fail validation.

Acquire a client_credentials token against the API's scope. AADSTS500011 means the resource principal was deleted and the consumer points at a dead identity; AADSTS501051 means the scope is right but the app-role assignment was destroyed, which a config change cannot fix.

SPAs use delegated scopes via authorization-code plus PKCE and are never assigned app roles, so AADSTS501051 on a client_credentials test is expected and proves nothing. Instead compare the ConfigMap VITE_AUTH_CLIENT_ID against the current Entra app registration.

Redeploy only when the config itself is wrong, such as a stale client ID in a ConfigMap; use rollout restart when config is right but the process is stuck. Never do a clean release, since it rebuilds the app registration and breaks every consumer.

Auth values flow from Secrets Manager through ESO into Secrets and envFrom, so every ReplicaSet reads the same current Secret. Rolling back Kubernetes objects changes nothing because the stale credential lives outside the cluster state.