Azure Managed Identity – Function App & Storage Account – DefaultAzureCredential fails but ManagedIdentityCredential succeeds
Problem Description:
I want to use user assigned identities for managing access between my resources. I have created an identity which has access the following roles for my storage account:
Storage Blob Data Owner
Storage Account Contributor
Storage Table Data Contributor
Storage Queue Data Contributor
I am writing this change in C#. When I use
var tableUri = new Uri(string.Format("https://{0}.table.core.windows.net/", storageAccountName));
var credential = new ManagedIdentityCredential(storageAccessClientId);
services.AddScoped(x => new TableServiceClient(tableUri, credential));
Everything works fine, I can access my table without any issue.
the problem is that I need to use DefaultAzureCredential() for my use case to avoid needing to pass down the storageAccessClientId environment variable. According to the documentation, this should work without any issue since it’s supposed to go through a chain of permissions till it finds the right one. It does not.
Clearly I have the identity correctly configured since I can access it if I explicitly tell Azure what ID to use, but when it attempts this on it’s own, it fails and I have spent days now trying to understand why.
One thought I have is that, for some sort of azure behind the scenes magic, it says I need to set AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, and AZURE_TENANT_ID. Is it possible that it’s ignoring my User Assigned Managed Identities and just grabbing the AZURE_CLIENT_ID variable?
I think I found my answer and if this is still the case in 2022, then it truly indicates a sad state of Azure. This and this are github issues where Azure devs specifically say that their IAM system is not sophisticated enough to find the user assigned permissions attached to the existing resource unless you explicitly state what you want. Coming from AWS this seems completely unacceptable, and I am hoping that this is another case of "azure keeps a lot of old documentation around, so keep looking for the newest truth".. but from everything I’ve tried it seems that this is actually how it works.
If anyone can show me differently, please let me know because I do not want to use System Managed Identities unless absolutely necessary. (Another SO ticket for that coming…)
Solution – 1
Azure does not provide functionality to handle multiple assigned identities dynamically. You need to help it along by telling it exactly what identity to use in each situation that you would like to use an Identity attached to your service (functiona app, web app, etc)
This was not acceptable for our needs, since we wanted dynamic identity access, so we stopped going down this route and opted for connection strings instead, sadly