-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG]Azure.Identity 1.13 Breaks DefaultAzureCredential On DevBox #46679
Comments
Thank you for your feedback. Tagging and routing to the team member best able to assist. |
This is possibly related to #46653 |
We're also running into this error running on our DevBox. We're using the Azure.Identity in combination with the
And its complete StackTrace:
|
Thanks for reporting - I am investigating. |
Hi @keggster101020 Also, could you enable logging and share that with me for the failure scenario? For console output, you would just need to add the following line to your program. using AzureEventSourceListener listener = AzureEventSourceListener.CreateTraceLogger(); If you need to log the output somewhere other than the console, this is described in these docs. var options = new DefaultAzureCredentialOptions
{
ExcludeEnvironmentCredential = true,
ExcludeWorkloadIdentityCredential = false,
ExcludeManagedIdentityCredential = false,
ExcludeAzureDeveloperCliCredential = true,
ExcludeSharedTokenCacheCredential = true,
ExcludeVisualStudioCredential = true,
ExcludeVisualStudioCodeCredential = true,
ExcludeAzureCliCredential = true,
ExcludeAzurePowerShellCredential = true,
ExcludeInteractiveBrowserCredential = false
};
var cred = new DefaultAzureCredential(options); |
Same issue is happening from Azure DevOps pipelines while connecting to an Azure SQL Database within an AzureCli@2 task. Pipeline is executing EF Core SQL migrations executable against Azure SQL connecting as the pipeline identity (federated ARM service connection). Upgrading to 1.13.0 breaks with a very similar error. Downgrading back to 1.12 resolves the issue. Not sure which token source is being picked up in 1.12 but sounds like it should use
|
@christothes I can look to grab a more official repro when I get some time (I tore down the devbox as part of the testing). However, part of my scenario was also access key vault using configuration builder extensions and the error @rdvanbuuren-gasunie posted above should be reflective of the error that I saw as well. Also, I did test the DefaultAzureCredential scenario disabling all providers except VS and interactive and I can confirm that that did resolve my issue. However, I still see this as a regression since prior to 1.13.0 the logic was as I described above: failures wouldn't break the entire chain they would only be thrown back if nothing in the chain resolved. |
@keggster101020 I totally agree that a change of behavior would be a regression, I was only asking about the alternative config for troubleshooting purposes since I cannot reproduce this locally. When I fetch a token using |
Hi @keggster101020. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue. |
@keggster101020 or @rdvanbuuren-gasunie - could you share the relevant parts of your configuration for the credential that reproduces the error in that scenario? |
Yes, of course! We're runnig a .NET 4.8 website using IISExpress on a DevBox, with the following configuration in the Web.config: <configuration>
<configSections>
<section name="configBuilders" type="System.Configuration.ConfigurationBuildersSection, System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" restartOnExternalChanges="false" requirePermission="false" />
</configSections>
<configBuilders>
<builders>
<add name="AzureKeyVault" vaultName="${KEY_VAULT_NAME}" type="Microsoft.Configuration.ConfigurationBuilders.AzureKeyVaultConfigBuilder, Microsoft.Configuration.ConfigurationBuilders.Azure, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</builders>
</configBuilders>
<appSettings configBuilders="AzureKeyVault">
<!-- From KeyVault -->
<add key="ClientSecret" value="" />
</appSettings>
</configuration> This should load the ClientSecret from the KeyVault secrets into the appSetting. If you need anymore information, I'm happy to help! |
@christothes for the Azure DevOps Workload/Federated Identity issue (see my comment above), shall I open a new issue or keep it in this thread? |
I believe that issue is fixed by #46711 |
seeing the same issue with 13 in devbox |
Hi @aherrick - Could you clarify which issue specifically? |
We are seeing a similar issue currently within an Azure DevOps pipeline. Within the TestFixture, the connection to AzureAppConfiguration is authenticated using After updating to
with
The issue is, we are not using ManagedIdentity Authentication anywhere in the devops pipeline, but instead rely on Azure CLI Credentials. I assume that these mentioned breaking changes are somewhat related, but I really cannot find any EnvironmentVariable or other parameter in the pipeline that would match any of these...
An alternative explanation would be that, some other errors in the authentication flow of ManagedIdentityCredential that were silently caught in the previous version, eventually leading to the factory to traverse further through the configured identity providers, now actually make the process fail early, and not providing the factory with the chance to continue... From my local dev-machine everything is running as expected, so there must be something on the MS Hosted agent in devops, that now make the library think it should use ManagedIdentity... |
Ok, looks like, this is also being solved by #46711 Still I would be curious to understand what is making the lib in 1.13.0 assume that it has to try ManagedIdentity in the first place 🤔 |
I can confirm this issue. Create a simple console application IdentityTest.csproj
Program.cs
Run in a pipeline using Pipeline:
The pipeline will succeed when using Azure Identity 1.12.1 When using Azure Identity 1.13.0 will produce this error:
|
Thanks @phelm1-landolakes - I have a local repro now and I have a fix. |
@phelm1-landolakes Would you mind verifying with your repro also using this latest build? 1.14.0-alpha.20241023.3 |
@christothes Using package version |
This is now available on the public nuget as 1.13.1 |
Can someone please confirm if this problem is resolved in version 1.13.1? I have recently gotten this error and my Azure.Identity is updated to version 1.13.1. I tried the latest version as well |
@MHDBST - If you are seeing the same error with 1.13.1, please open a new issue with the specific details of your issue. It may be a different problem. |
Library name and version
Azure.Identity 1.13
Describe the bug
My code is using
DefaultAzureCredential(true)
to authenticate to remote azure resources. After upgrading Azure.Identity to 1.13 a handful of users are noting that they are getting the following error when running inside of Microsoft DevBox:There are no assigned identities to these DevBoxes (we are using the
devbox.microsoft.com
instances not selfhosted). Downgrading to 1.12 seems to have resolved this issue but putting this bug here as it seems like the detection logic aroundDefaultAzureCredential
may be incorrect in 1.13.I was under the impression that
DefaultAzureCredential
was a chained credential and that any failures in the chain would only be thrown back to the user if none of the credentials in the chain succeeded. However, the interactive popup never showed up, also some users have the VSCredential and the MI credential error happens seemingly as soon as it fails.Expected behavior
Using
DefaultAzureCredential(true)
inside a DevBox VM with no managed identity would attempt other credentials in the chain before throwing an exception back to the user.Actual behavior
DefaultAzureCredential(true)
throws an exception on DevBoxes if there is no MSI attached to the devbox and doesn't attempt any further credential operations.Reproduction Steps
new DefaultAzureCredential(true).GetTokenAsync(<some token request context>)
Environment
Microsoft Devbox (https://devbox.microsoft.com/)
The text was updated successfully, but these errors were encountered: