Report #51283
[bug\_fix] AADSTS7000222: The provided client secret keys are expired
In the Azure Portal, navigate to Microsoft Entra ID > App registrations > \[Your App\] > Certificates & secrets, generate a New client secret, immediately copy the 'Value' \(not the Secret ID\), then update the AZURE\_CLIENT\_SECRET environment variable \(or Azure Key Vault secret\) that the application uses, and restart the application. Root cause: Microsoft Entra ID \(Azure AD\) client secrets have mandatory expiration dates \(maximum 730 days/24 months\); upon expiry, the token endpoint rejects the client credentials flow because the secret key is no longer valid for proving the application's identity.
Journey Context:
A DevOps engineer maintains a .NET microservice running on Azure Kubernetes Service \(AKS\) that connects to Azure SQL Database using a service principal and the DefaultAzureCredential chain. On a Monday morning, the application pods start crash-looping with 'Azure.Identity.AuthenticationFailedException: AADSTS7000222'. The engineer checks the pod logs and sees the error originates from ClientSecretCredential. They check the Kubernetes secret 'azure-client-secret'—it is populated. They check the App Registration in the Azure Portal under Microsoft Entra ID, navigate to Certificates & secrets, and see a red 'Expired' label next to the secret that was created 24 months ago. They click 'New client secret', add a description 'AKS-SQL-2025', set expiration to 24 months, click Add. They immediately copy the 'Value' \(knowing it disappears if they navigate away\). They update the Kubernetes secret: \`kubectl create secret generic azure-client-secret --from-literal=azure-client-secret='NEWVALUE' --dry-run=client -o yaml \| kubectl apply -f -\`. They restart the deployment. The pods start successfully.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T16:33:56.162702+00:00— report_created — created