Bug Report
| Package |
Version |
| github.com/Azure/azure-sdk-for-go/sdk/azidentity |
v1.13.1 |
If you call NewDefaultAzureCredential() the chain that's returned includes a ManagedIdentityCredential that's configured to "play-nicely" with other credentials: It does an up-front probe for IMDS availability to avoid triggering timeouts and other problems when authenticating.
We discovered this when our command-line app asoctl failed to authenticate, encountering timeouts and io/errors due to MI unavailability on the command line.
If you instead construct the token chain yourself (following recommended practices to take control over how your application can authenticate), this behaviour can't be replicated because the required flag is private.
In the azure-service-operator project we worked around this by detecting IMDS ourselves but it would be better if we didn't need to do this.
The internal flag is set in default_azure_credential.go:
o := &ManagedIdentityCredentialOptions{
ClientOptions: options.ClientOptions,
// enable special DefaultAzureCredential behavior (IMDS probing) only when the chain contains another credential
dac: selected^managedIdentity != 0,
}Expectation: We should be able to construct our own chained-credential that behaves precisely how the default one works.
This could be done by
- Allowing us to set the
dac field ourselves; or
- Having
NewChainedTokenCredential() set the internal flag if/when the chain includes a ManagedIdentityCredential
The later option would be both backward-compatible and a fix for anyone inadvertently encountering errors at the moment.
Bug Report
If you call
NewDefaultAzureCredential()the chain that's returned includes aManagedIdentityCredentialthat's configured to "play-nicely" with other credentials: It does an up-front probe for IMDS availability to avoid triggering timeouts and other problems when authenticating.We discovered this when our command-line app
asoctlfailed to authenticate, encountering timeouts and io/errors due to MI unavailability on the command line.If you instead construct the token chain yourself (following recommended practices to take control over how your application can authenticate), this behaviour can't be replicated because the required flag is private.
In the azure-service-operator project we worked around this by detecting IMDS ourselves but it would be better if we didn't need to do this.
The internal flag is set in default_azure_credential.go:
Expectation: We should be able to construct our own chained-credential that behaves precisely how the default one works.
This could be done by
dacfield ourselves; orNewChainedTokenCredential()set the internal flag if/when the chain includes aManagedIdentityCredentialThe later option would be both backward-compatible and a fix for anyone inadvertently encountering errors at the moment.