Consistent 400 response code followed by 200 when using ManagedIdentityCredential
See original GitHub issueWe have a VMSS with multiple user assigned identities. We noticed that when we use the ManagedIdentityCredential
, the SDK always makes 2 subsequent GET requests to the /metadata/identity/oauth2/token
endpoint on the VM - the first one returns 400, and the second one returns 200.
Does the first call return 400 by design?
Issue Analytics
- State:
- Created a year ago
- Comments:8 (4 by maintainers)
Top Results From Across the Web
Issues · Azure/azure-sdk-for-js · GitHub
Consistent 400 response code followed by 200 when using ManagedIdentityCredential Azure.Identity Client This issue points to a problem in the data-plane of ...
Read more >App throws error: ManagedIdentityCredential authentication ...
App throws error: ManagedIdentityCredential authentication ... Status: 400. I've followed the Microsoft Ingest-iot-hub-data tutorial: ...
Read more >HTTP 403 Forbidden | What is 403 Forbidden Error and How ...
HTTP 403 forbidden error code means that the server understood the request but will not process it. Learn more about 403 forbidden error ......
Read more >Investigating and fixing the HTTP "Client.response.code 403 ...
... fixing the HTTP "Client.response.code 403" with custom-configured exception triggered. book. Article ID: 236416. calendar_today. Updated On: 08-03-2022 ...
Read more >DefaultAzureCredential throwing unknown error
I am trying to set up a Azure webapp service (uses docker) to access my keyvault using a user manged ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
The resource is indeed keyvault, and we run on K8S with VMSS which has a user assigned identity. Since the second request consistently returns 200 and the 400 has no real impact on us, I think the issue can be closed for now, and in case I will see that it causes any problem, I will reopen.
@guy-microsoft
Which azure resource are you trying to access? If it is keyvault, then it does return 401 by design. In case of Kubernetes too, if you are seeing the 400 response consistently, it may happen that the pods might take some time initially to warm up and the imds endpoint might not be available.
You could either add a retry (though we do have the retry in our identity code) or slight initial delay and see if it helps? Let me know if this works for you.
In order to verify how many retries are done by the @azure/identity library, you could add this code snippet - In package.json dependencies section add : “@azure/logger”: “^1.0.3”
If you are using JS, add this code snippet:
OR if you are using TS, add this code snippet:
After running the code, check the logs and look for the retry policy
azure:core-rest-pipeline retryPolicy:info Retry 0
Also are you using Kubernetes or Azure VM for managed identity?
A verification for endpoint availability check that you can run on your end - if you are using managed identity on VM - When you receive the 400 response from the sdk, you should also receive the 400 response when you try this curl command - https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/identity/identity/TROUBLESHOOTING.md#verify-imds-is-available-on-the-vm which shows that the endpoint is not available.