0

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?

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

191180rk
  • 735
  • 2
  • 12
  • 37
  • On the function do you have a system-assigned identity as well ? What about the VMSS, only user-assigned identity ? – Thomas Aug 30 '21 at 21:43
  • 1
    Have you seen this discussion threat: https://github.com/Azure/azure-sdk-for-net/issues/11400 ? Looks like a limitation of app service (web and function app). – Thomas Aug 30 '21 at 22:02
  • referred this link long back. But still wondering, how my other app deployed on Azure VMSS establishing handshake with Azure key vault without including the specific user msi in its appsettings even though system MSI is turned off? – 191180rk Aug 31 '21 at 09:35
  • I would assume the underlying infrastructure of app service is different from VMSS so it has some limitations. – Thomas Aug 31 '21 at 09:37

1 Answers1

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://learn.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.

Matt Small
  • 2,182
  • 1
  • 10
  • 16
  • @ Matt Small, 1) if "it's a problem with the request" then how just adding "AZURE_CLIENT_ID" to Azure function appsettings resolves the issue? 2) "when using a User-Assigned Identity, you always have to be explicit about the identity" then how unlike Azure function, the web api application hosted on "user assigned MI" enabled VMSS manages to get valid AAD token to access key vault without explicit mentioning of VMSS User-Assigned Identity in its appsettings? – 191180rk Aug 28 '21 at 08:41
  • Let me understand: what does the “azure_client_id” look like? I want to be aure we’re on the same page. Also, I don’t know why your other app is working without including the specific user msi, but I am sure that there’s something configured differently that you haven’t realized yet. – Matt Small Aug 29 '21 at 12:22
  • @ Matt Small, "something configured differently that you haven’t realized yet" maybe. Also interest to know how my other app deployed in Azure VMSS is working without including the specific user msi. I'm using Azure_Client_Id: mi-vmss-myapp1node-dev – 191180rk Aug 30 '21 at 05:08
  • Also updated the error message received from Azure function if user msi i.e., AZURE_CLIENT_ID not included in the appsettings. – 191180rk Aug 30 '21 at 08:07
  • Edited the answer to include more information. As for your VMSS, I don't know why it seemingly works without the explicit user-assigned identity information. My guess is either that it's actually using system-assigned and that you also have an access policy in the Key Vault for that identity, or that the user-identity has actually been configured for VMSS. – Matt Small Aug 30 '21 at 15:12
  • 1
    @ Matt Small, totally agree with your point why we need explicit mentioning of user MI, as it is required to pick from the list of user MIs. But on VMSS how it is working with explicit mentioning of user MI (provided even though system MI is turned off for that specific VMSS). One thing which differentiate VMSS & App service is as you know they are IaaS & PaaS respectively, whether this difference play a role in the manner how user-assigned identity is retrieved between these two resource, not sure. Some help/direction would be helpful. – 191180rk Aug 31 '21 at 09:32
  • You could review the Key Vault logs to ensure that when the VMSS accesses the vault, the correct user-assigned identity is working. If that's the case, then somehow your UserMSI is assigned to the VMSS. I can't tell you how without seeing it live. If it's using a different identity then you have other troubleshooting to do. – Matt Small Sep 02 '21 at 14:53