Az cli response slow on docker containers

[jeethendrad]

Describe the bug

Hi Team,
Cx is running Redhat 8 Azure VM
-They have installed docker inside Azure VM and created multiple containers.

-The az cli version installed on the VM level is latest 2.75. No issues on VM level.
-However, they have installed az cli on each of above containers inside the VM. One of the container has 2.72 and that is running fine.
-The other containers have 2.74 version, and they run slow more then 20 seconds to respond.
-This is same for all the commands, we took two commands as example.. az login --identity and other is az group list.

The debug log outputs have been attached here.
The only difference between fast and slow is that the access token is in cache while the slow container fetches token.
To contradict on this, Azure VM level does same steps as the slow container but the response on Azure VM level is fast. 2seconds vs 20seconds.

Related command

az login --identity --client-id
az group list

Errors

No errors

Issue script & Debug output

Expected behavior

Less than few seconds of response

Environment Summary

Azure VM az version 2.75 Fast
Container 1 az version 2.72 Fast
Container 2 az version 2.74 Slow

Additional context

No response

[yonzhan]

Thank you for opening this issue, we will look into it.

[jiasli]

Azure CLI doesn't not use token cache for managed identity authentication, no matter if it is using msrestazure or MSAL. For example, with MSAL, the token_cache argument is not set when creating ManagedIdentityClient:

azure-cli/src/azure-cli-core/azure/cli/core/auth/msal_credentials.py

Line 148 in 5c3cf2f

self._msal_client = ManagedIdentityClient(managed_identity, http_client=requests.Session())

A new access token is always retrieved from the IMDS endpoint for each command, as the debug log shows:

With Azure CLI 2.72 (msrestazure):

msrestazure.azure_active_directory: MSI: Retrieving a token from http://169.254.169.254/metadata/identity/oauth2/token, with payload {'resource': 'https://management.core.windows.net/', 'api-version': '2018-02-01', 'client_id': '60f83f99-3023-43d5-ad45-7a81d5e5c833'}
msrestazure.azure_active_directory: MSI: Token retrieved
cli.azure.cli.core._debug: Using CA bundle file at '/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem'.
cli.azure.cli.core.auth.adal_authentication: MSIAuthenticationWrapper.get_token: scopes=('https://management.core.windows.net//.default',), kwargs={}
msrestazure.azure_active_directory: MSI: token is found in cache.

With Azure CLI 2.74 (MSAL):

msal.managed_identity: Obtaining token via managed identity on Azure VM
urllib3.connectionpool: Starting new HTTP connection (1): 169.254.169.254:80
urllib3.connectionpool: http://169.254.169.254:80 "GET /metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fmanagement.core.windows.net%2F&client_id=60f83f99-3023-43d5-ad45-7a81d5e5c833 HTTP/1.1" 200 2403

I doubt there is some problem with the container's network.

Could you follow #28786 (comment) to add the timestamp to the debug log of the slow execution, which can help us identity which step takes longer than expected?

[jiasli]

Judging by the debug log:

# get_token_info protocol is called
2025-08-04T16:11:33.479794770Z DEBUG: cli.azure.cli.core.auth.credential_adaptor: CredentialAdaptor.get_token_info: scopes=('https://management.core.windows.net//.default',), options={}

# Azure CLI calls MSAL
2025-08-04T16:11:33.483704074Z DEBUG: cli.azure.cli.core.auth.msal_credentials: ManagedIdentityCredential.acquire_token: scopes=['https://management.core.windows.net//.default'], kwargs={}

# 20 seconds later, MSAL makes a call to IMDS
2025-08-04T16:11:53.512299079Z DEBUG: msal.managed_identity: Obtaining token via managed identity on Azure VM
2025-08-04T16:11:53.516564375Z DEBUG: urllib3.connectionpool: Starting new HTTP connection (1): 169.254.169.254:80
2025-08-04T16:11:53.528778976Z DEBUG: urllib3.connectionpool: http://169.254.169.254:80 "GET /metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fmanagement.core.windows.net%2F&client_id=60f83f99-3023-43d5-ad45-7a81d5e5c833 HTTP/1.1" 200 2402

The longest delay happens after Azure CLI invokes MSAL, but before MSAL makes the real HTTP request. Note there is no complex task between log printing (L151) and MSAL acquire_token_for_client invocation (L154):

azure-cli/src/azure-cli-core/azure/cli/core/auth/msal_credentials.py

Lines 151 to 154 in 5c3cf2f

	logger.debug("ManagedIdentityCredential.acquire_token: scopes=%r, kwargs=%r", scopes, kwargs)
	from .util import scopes_to_resource
	result = self._msal_client.acquire_token_for_client(resource=scopes_to_resource(scopes))