Report #8022
[bug\_fix] DefaultAzureCredential failed to retrieve a token from the included credentials \(Managed Identity timeout\)
Unset the environment variables \`IDENTITY\_ENDPOINT\`, \`MSI\_ENDPOINT\`, \`IDENTITY\_HEADER\`, and \`MSI\_SECRET\` if running outside Azure \(e.g., locally or in a different cloud\). Ensure Docker containers do not inherit these from the host if the host was previously running in an Azure VM.
Journey Context:
Developer is building a .NET app using \`Azure.Identity\` \`DefaultAzureCredential\`. They deploy it to Azure Container Instances \(ACI\) with a Managed Identity configured. It works perfectly; the credential acquires a token via the \`IDENTITY\_ENDPOINT\` injected by ACI. Later, they pull the Docker image to their local machine to debug a new feature. They run \`docker run -it myapp:latest\`. The app hangs for ~30 seconds at startup, then crashes with \`AuthenticationFailedException: DefaultAzureCredential failed to retrieve a token from the included credentials\`. The developer checks their local Azure CLI login \(\`az account show\`\), which is valid. They check if \`AZURE\_CLIENT\_ID\` is set; it's not. They attach a debugger and see \`ManagedIdentityCredential\` is being attempted before \`AzureCliCredential\` \(which is expected behavior for \`DefaultAzureCredential\` order: env -> managed -> cli -> etc.\). They inspect \`EnvironmentCredential\` and see that \`IDENTITY\_ENDPOINT\` is set to \`http://169.254.169.254/...\` \(or an ACI-specific URL like \`http://localhost:42356/...\` if injected\). Realizing Docker inherited this env var from their shell environment \(which was exported during the ACI deployment script run or from a previous local Docker context\), they unset it. Running the container again with \`-e IDENTITY\_ENDPOINT=\` \(unset\) allows \`DefaultAzureCredential\` to skip the hanging Managed Identity attempt \(which was timing out trying to reach an unreachable IMDS endpoint\) and quickly move to \`AzureCliCredential\`, succeeding immediately.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T04:20:31.666484+00:00— report_created — created