azure-sdk-for-net
azure-sdk-for-net copied to clipboard
[BUG] DefaultAzureCredential fails to move past ManagedIdentity on Docker Desktop
Library name and version
Azure.Identity 1.10.4
Describe the bug
Using DefaultAzureCredential and Docker Desktop on a windows PC the credential stops at ManagedIdentityCredential (when running locally). Expected behaviour would be to move on to az cli credential (that is available). Replacing the DefaultAzureCredential with AzCliCredential or turning off Managed Identity Credentials locally is the current workaround. This is not really an ideal solution, as Managed Identity Credentials is used in the actual environment.
The error message is as follows;
2024-02-22 10:52:48 Status: 403 (connecting to 169.254.169.254:80: connecting to 169.254.169.254:80: dial tcp 169.254.169.254:80: connectex: Det ble forsøkt en kontaktoperasjon til et nettverk som ikke kunne nås.) 2024-02-22 10:52:48 2024-02-22 10:52:48 Headers: 2024-02-22 10:52:48 Connection: close 2024-02-22 10:52:48 2024-02-22 10:52:48 See the troubleshooting guide for more information. https://aka.ms/azsdk/net/identity/managedidentitycredential/troubleshoot 2024-02-22 10:52:48 ---> Azure.RequestFailedException: Service request failed. 2024-02-22 10:52:48 Status: 403 (connecting to 169.254.169.254:80: connecting to 169.254.169.254:80: dial tcp 169.254.169.254:80: connectex: Det ble forsøkt en kontaktoperasjon til et nettverk som ikke kunne nås.) 2024-02-22 10:52:48 2024-02-22 10:52:48 Headers: 2024-02-22 10:52:48 Connection: close 2024-02-22 10:52:48 2024-02-22 10:52:48 at Azure.Identity.ManagedIdentitySource.HandleResponseAsync(Boolean async, TokenRequestContext context, Response response, CancellationToken cancellationToken) 2024-02-22 10:52:48 at Azure.Identity.ImdsManagedIdentitySource.HandleResponseAsync(Boolean async, TokenRequestContext context, Response response, CancellationToken cancellationToken) 2024-02-22 10:52:48 at Azure.Identity.ManagedIdentitySource.AuthenticateAsync(Boolean async, TokenRequestContext context, CancellationToken cancellationToken)
There was an attemped fix to this problem in #41306 - but since my OS is in another language than English the new error matching does not have any effect.
Expected behavior
That ManagedIdentityCredential returns CredentialUnavailableException and it continues with the next credential,
Actual behavior
It fails using ManagedIdentityCredential, the error message is not treated as a CredentialUnavailableException, and the execution stops.
Reproduction Steps
Have an OS that is not in English (so that you get a localized error message):
- Run a container in docker desktop that at any point uses DefaultAzureCredential with ManagedIdentityCredential turned on.
Environment
No response
@christothes @heaths
Thank you for your feedback. Tagging and routing to the team member best able to assist.
The problem is also happening in french. Here's the error message:
Unhandled exception. Azure.Identity.AuthenticationFailedException: ManagedIdentityCredential authentication failed: Service request failed.
Status: 403 (connecting to 169.254.169.254:80: connecting to 169.254.169.254:80: dial tcp 169.254.169.254:80: connectex: Une opération a été tentée sur un réseau impossible à atteindre.)
If I use the following command, as recommended by the troubleshooting guide: curl 'http://169.254.169.254/metadata/identity/oauth2/token?resource=https://management.core.windows.net&api-version=2018-02-01' -H "Metadata: true"
, I get the same message, minus the encoding errors:
connecting to 169.254.169.254:80: connecting to 169.254.169.254:80: dial tcp 169.254.169.254:80: connectex: Une opération a été tentée sur un réseau impossible à atteindre.
Here are the lines that trigger the problem:
var credentials = new DefaultAzureCredential();
_ = config.AddAzureKeyVault(vaultURI, credentials);
The message appears when I run my application locally. We are working in a devcontainer, so the application runs in a docker container.
The workaround so far is simply using the EnvironmentCredential
class and setting the AZURE_CLIENT_ID, AZURE_TENANT_ID and AZURE_CLIENT_SECRET variables manually. But we'd like to eventually be able to use the azure command line to log in locally and use a managed identity when we deploy on Azure.
Whatever the fix is, it should not be dependant on the langage of the exception, as it definitly will happen to another user that has its OS in another langage.
connectex
seems to be in all error messages, despite the langage. Maybe the match could be based on that?
I'm working with the IMDS team to ensure we can differentiate between a legitimate 403 indicating failure, and the one that comes from Docker. We'll push a fix once we have something.
We run into the same problem on German system using "Authentication=Active Directory Default". Please take into account that this is only working in vulnerable versions <= 1.9.0. We are waiting for an update since 8/2023.
fixed with #45236