DefaultAzureCredential doesn't work with User Assigned Managed Identity in Azure App Service while thats not the case with Azure VMSS

Question

Enabled same "user assigned managed identity" for Azure VMSS as well as for Azure function app.

Added the MI to the access policy of Azure key vault.

On below application hosts, using "DefaultAzureCredential" trying connect to the Azure key vault to read application secrets,

1. From the application deployed on Azure VMSS, with out any hassle can able to connect to the Azure key vault to read application secrets using "DefaultAzureCredential" api

2. Where as from Azure function can't able to connect to keyvault using "DefaultAzureCredential" api, it throws below exception

   Error occurred while trying to connect to Key Vault. Azure.Identity: ManagedIdentityCredential authentication failed: Service request failed. Status: 400 (Bad Request)

Overcome the above issue in Azure function app by adding explicit "AZURE_CLIENT_ID" variable in appsettings and by assigning "user assigned managed identity" name to it.

Would like to know, why there is difference in behaviour of "DefaultAzureCredential"api while consuming it in Azure VMSS vs Azure function app where explicit mentioning of "AZURE_CLIENT_ID" required? what is the rationale here?

PS: the above mentioned happening only with user assigned not system assigned managed identity.

Answer 1

This isn't a problem with the identity, it's a problem with the request. HTTP 400 means that something is wrong with the token submitted to the Key Vault. If this was a 403 then it would have been rejected because of the access policy.

Additionally, when using a User-Assigned Identity, you always have to be explicit about the identity you want to use. That's why it works.

===Additional information===

https://docs.microsoft.com/en-us/azure/app-service/overview-managed-identity?tabs=dotnet#add-a-user-assigned-identity

If you want to use a user-assigned managed identity, you can set the AzureServicesAuthConnectionString application setting to RunAs=App;AppId=. Replace with the client ID of the identity you want to use.

Additionally, there's this information:

client_id The client ID of the user-assigned identity to be used. Cannot be used on a request that includes principal_id, mi_res_id, or object_id. If all ID parameters (client_id, principal_id, object_id, and mi_res_id) are omitted, the system-assigned identity is used.

All this said, I would need to see exactly how you've set all of this up in order to get the user-assigned identity working. The thing is with a user-assigned identity is that you can create many of them so each service has to be told specifically which one it should use. That's not the case with system-assigned identity because there's exactly one per service - if you don't tell the service to use a specific user-assigned identity, it assumes you want the system-assigned identity.