[BUG]Azure.Identity 1.13 Breaks DefaultAzureCredential On DevBox #46679
Assignees
Labels
Azure.Identity
Client
This issue points to a problem in the data-plane of the library.
customer-reported
Issues that are reported by GitHub users external to the Azure organization.
needs-author-feedback
Workflow: More information is needed from author to address the issue.
question
The issue doesn't require a change to the product in order to be resolved. Most issues start as that
Comments
github-actions
bot
added
Azure.Identity
Client
|
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 |
christothes
added
the
needs-author-feedback
github-actions
bot
removed
the
needs-team-attention
|
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! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.cominstances not selfhosted). Downgrading to 1.12 seems to have resolved this issue but putting this bug here as it seems like the detection logic aroundDefaultAzureCredentialmay be incorrect in 1.13.I was under the impression that
DefaultAzureCredentialwas 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: