Closed giulianob closed 1 week ago
Thank you for your feedback. Tagging and routing to the team member best able to assist.
Hi @giulianob - This is the expected default behavior.
If you want to customize the retry behavior, this can be done by customizing the RetryOptions on the options passed to the ManagedIdentityCredential
Hi @giulianob. 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.
@christothes I haven't been able to find a way to accomplish the same thing as what DefaultAzureCredentials
does without some hacking around. I believe I would have to essentially re-implement what is available internally but not exposed:
Metadata
header to do the probing requestI understand this is currently the expected behavior but this is a design bug IMO if using managed identity within the ChainedTokenCredential
takes ~25s every time.
If you want the probe behavior, you could replace ManagedIdentityCredential
with DefaultAzureCredential
in your chain and construct it with DefaultAzureCredentialOptions
setting all the Exclude*Credential
properties set to true
except for ExcludeManagedIdentityCredential
.
I understand this is currently the expected behavior but this is a design bug IMO if using managed identity within the ChainedTokenCredential takes ~25s every time.
ManagedIdentityCredential
is designed to be resilient when attempting to connect to the IMDS endpoint and will retry exponentially. As mentioned in my previous reply, the retry behavior can be customized. However, since it is not constructed by the ChainedTokenCredential
it is not aware that it is part of a chain and will not be configured with the probing behavior.
Hi @giulianob. 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.
@christothes: we understand the behavior is as designed. Our comment is that the behavior as designed caused an unexpected issue for us. As @giulianob pointed out, any customer that hits the unexpected issue would need to recreate the retry behavior themselves. If the retry behavior in DefaultAzureCredential
were easier to use it would have made this issue easier to solve.
Hi @giulianob, since you haven’t asked that we /unresolve
the issue, we’ll close this out. If you believe further discussion is needed, please add a comment /unresolve
to reopen the issue.
Library name and version
Azure.Identity 1.12
Describe the bug
The
ManagedIdentityCredential
will probe IMDS and fail quickly but this only works when it's created viaDefaultAzureCredential
. If aManagedIdentityCredential
is manually created and and used within aChainedTokenCredential
theManagedIdentityCredential
will keep retrying and take ~25 seconds to fail.Expected behavior
Ability to leverage the probing functionality of
ManagedIdentityCredential
without needing to rely onDefaultAzureCredential
.Actual behavior
(See repro steps below for the full error output)
Reproduction Steps
Sample:
Full output with telemetry:
Environment
No response