search

Azure / azure-sdk-for-net

This repository is for active development of the Azure SDK for .NET. For consumers of the SDK we recommend visiting our public developer docs at https://learn.microsoft.com/dotnet/azure/ or our versioned developer docs at https://azure.github.io/azure-sdk-for-net.
MIT License
5.48k stars 4.81k forks source link

[FEATURE REQ] add environment variable to disable ManagedIdentityCredential from DefaultAzure Credential #43258

Closed drdamour closed 6 months ago

drdamour commented 7 months ago

Library name

Azure.Identity

Please describe the feature.

opening in .net but would love this option for java too.

lots of my colleagues experience the 10ish second penalty #39295 and #29471 when running locally when a lib depends on Azure.Identity. This code is not ours, it's the Microsoft.Data.SqlClient implementation mostly https://github.com/dotnet/SqlClient/blob/9811c657db1cd1ddc270addc9221579df32af6ba/src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/ActiveDirectoryAuthenticationProvider.cs#L152 that gives no chance to override the config...but other tools/libs do this too w/ no option to override behaviour from the outside. in java it's mulesoft anypoint implementations.

another case was a company provided azure virtual desktop for a dev that they had added a managed identity to for provisioning, but that identity wasnt granted any permission (by design). i had no recourse and couldn't use my VS creds, had to setup an SP and use lient credentials flow.

i miss the old days of the prior lib b4 azure.identity that let you control all the delegated credential clients in the chain with env vars..but i'll settle for just being able to exclude the managed identity one to save my colleagues some headaches.

i suggest name be like DEFAULT_AZ_CRED_DISABLE_<type>

github-actions[bot] commented 7 months ago

Thank you for your feedback. Tagging and routing to the team member best able to assist.

christothes commented 7 months ago

This change will ship tomorrow and should mitigate the long timeout.

github-actions[bot] commented 7 months ago

Hi @drdamour. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation.

drdamour commented 7 months ago

/unresolved this timeout improvement is good news, but doesnt address the real problem i have with running in avd's that have identity assigned out of my control or give no opportunity to opt out of their implementation of deafaultazurecredentialoptions. still think this should be considered

christothes commented 7 months ago

Hi @drdamour If you want a to disable managed identity credential even when deployed, then set the ExcludeManagedIdentityCredential property in the DefaultAzureCredentialOptions.

github-actions[bot] commented 7 months ago

Hi @drdamour. 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.

drdamour commented 7 months ago

@christothes as i linked originally https://github.com/dotnet/SqlClient/blob/9811c657db1cd1ddc270addc9221579df32af6ba/src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/ActiveDirectoryAuthenticationProvider.cs#L152 is a library from MS that gives me NO opportunity to configure the DefaultAzureCredentialOptions in the way you have suggested....there are MANY cases like this as people have built their own libraries and utilities on top of Azure.Identity that hide/encapsulate any ability to modify DefaultAzureCredentialOptions as youve have suggested.

Again this is really best made available in ALL the runtimes .net java etc, but .net is the most pressing for me, java a close second.

so please take a moment to fully understand the problem, then consider the suggestion fully.

christothes commented 7 months ago

@christothes as i linked originally https://github.com/dotnet/SqlClient/blob/9811c657db1cd1ddc270addc9221579df32af6ba/src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/ActiveDirectoryAuthenticationProvider.cs#L152 is a library from MS that gives me NO opportunity to configure the DefaultAzureCredentialOptions in the way you have suggested....there are MANY cases like this as people have built their own libraries and utilities on top of Azure.Identity that hide/encapsulate any ability to modify DefaultAzureCredentialOptions as youve have suggested.

Again this is really best made available in ALL the runtimes .net java etc, but .net is the most pressing for me, java a close second.

so please take a moment to fully understand the problem, then consider the suggestion fully.

DefaultAzureCredential is configurable via the AccessTokenCallback feature. Does that not work for your scenario?

github-actions[bot] commented 7 months ago

Hi @drdamour. 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.

github-actions[bot] commented 7 months ago

Hi @drdamour, we're sending this friendly reminder because we haven't heard back from you in 7 days. We need more information about this issue to help address it. Please be sure to give us your input. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!

drdamour commented 6 months ago

DefaultAzureCredential is configurable via the AccessTokenCallback feature. Does that not work for your scenario?

by reducing my broader set of scenarios down to this one specific case i can answer your misleading question (not far from "have you stopped beating your wife yet?") with a yes but that is because you limited my scenarios to a single case where i have access to change the code up to an including changing the Sql Data Client to a version that includes the AccessTokenCallabck which was only made available very recently. Prior to that 5.2 version it served as a great example of why not having an environment variable control is so limiting, prior to this recent addition i could not answer yes.

other library authors have encapsulated their use of Azure Identity libs the same as Sql Data Client did prior to 5.2 with no direct way to adjust their behaviour.

Further as mentioned initially specific runtime environments (like an azure virtual desktop where managed identity has been defined) make it so running compiled code based on azure-identity forces the use of the managed identity token.

the AccessTokenCallback feature CAN NOT address the breadth of scenarios that an environment variable could, and it's that breadth that i'm after with this feature request.

christothes commented 6 months ago

Thanks for confirming the new feature in SQLClient does allow configuration.

As for other scenarios, I'm hesitant to add another way to configure DefaultAzureCredential as the options are already quite complicated. Unfortunately, we can't control scenarios where other libraries encapsulate the use of this credential without exposing any way to configure it.

drdamour commented 6 months ago

we can't control scenarios where other libraries encapsulate the use of this credential without exposing any way to configure it

if you supported an environment variable, you could. also you continue to reduce my scenarios to serve your viewpoint. It's not just libraries...it's apps running in environments where managed identity is present but NOT the desired identity to leverage.

I get the desire to decrease complexity, but wish you'd reconsider given the quick ubiquity this lib is achieving across multiple runtimes. I'm likely just ahead of the curve here.