-
Notifications
You must be signed in to change notification settings - Fork 850
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
azidentity
: DefaultAzureCredentialOptions
to allow opting out some of the auth methods
#20502
Comments
We decided not to add such options because we want to keep the |
Hi @magodo. 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 “ |
Hi @magodo, since you haven’t asked that we “ |
@chlowell I have to disagree with you that azure-sdk-for-go/sdk/azidentity/default_azure_credential.go Lines 23 to 36 in 1a91847
Things like Apparently I can implement my own |
opts := azidentity.DefaultAzureCredentialOptions{}
if condition {
opts.DisableManagedIdentity = true
}
cred, err := azidentity.NewDefaultAzureCredential(&opts) Here's a way to get the same result with the current API: var cred azcore.TokenCredential
if condition {
cred, err := azidentity.NewAzureCLICredential(nil)
} else {
cred, err := azidentity.NewManagedIdentityCredential(nil)
} Does that work for your application? I'm sorry to have implied in my first response that more code is necessary. |
Hi @magodo. 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. |
@chlowell Yes, I could do that, whilst I still want to keep checking the environment variables for client certificate/secret auth method in the meanwhile. What I'm actually asking is kind of a togglable |
By design we do not allow modifying which credentials the DefaultAzureCredential uses. If you would like fine grained control over which credential is used and in which order, the proper approach is to use the ChainedTokenCredential. |
@RickWinter Would you mind to point which design are your referring to? I didn't recall there is a design principle about how the default auth should be like in the Azure SDK design principle. |
BTW, things like |
There's a note in the readme (see the bottom of this section). I'll add something similar to the API documentation. Why do you want to rewrite env, err := azidentity.NewEnvironmentCredential(nil)
if err != nil {
// TODO: handle error
}
creds := []azcore.TokenCredential{env}
if condition {
mi, err := azidentity.NewManagedIdentityCredential(nil)
if err != nil {
// TODO: handle error
}
creds = append(creds, mi)
}
cli, err := azidentity.NewAzureCLICredential(nil)
if err != nil {
// TODO: handle error
}
creds = append(creds, cli)
cred, err := azidentity.NewChainedTokenCredential(creds, nil) |
@chlowell Thanks for the illustration! But I noticed the |
Feature Request
Currently, the
DefaultAzureCredentialOptions
will always try each defined auth method in the fixed order. Imagine I have a VM and want to run some Go code on it to interact with ARM using this SDK, it will always try the MSI (i.e. the VM's identity) instead of falling back to using Azure CLI (i.e. my user account). The request sent from my App will then fail since I didn't give enough role to the VM, which I deliberately want to avoid.The text was updated successfully, but these errors were encountered: