Azure托管标识：Function App与存储账户DefaultAzureCredential失败问题

问题背景 #

我通过用户分配的托管标识管理Azure资源访问权限，已为存储账户配置以下角色：

• Storage Blob Data Owner
• Storage Account Contributor
• Storage Table Data Contributor
• Storage Queue Data Contributor

使用C#开发时，显式指定用户分配标识的Client ID可以正常访问表存储：

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));

但我希望使用DefaultAzureCredential()来避免传递storageAccessClientId环境变量，按官方文档它应该通过凭证链自动匹配权限，实际调用却失败。明确指定Client ID能正常访问，说明标识配置没问题，但自动查找时似乎忽略了用户分配的托管标识，只读取AZURE_CLIENT_ID变量。之前查GitHub Issue看到Azure开发人员提到IAM系统无法自动识别资源附加的用户分配权限，必须显式指定，想确认这个问题是否仍存在，同时寻求无需使用系统托管标识的解决方案。

问题确认 #

目前Azure SDK的DefaultAzureCredential在多用户分配托管标识的场景下，确实存在无法自动匹配对应权限标识的问题。当宿主环境（如App Service、VM）配置了多个用户分配标识时，DefaultAzureCredential不会自动遍历所有标识尝试匹配目标资源的权限，而是优先使用AZURE_CLIENT_ID环境变量指定的标识，或默认选择系统托管标识（如果存在）。如果没有设置AZURE_CLIENT_ID且不想用系统托管标识，它就无法自动找到正确的用户分配标识，导致权限验证失败。

解决方案（无需系统托管标识） #

方案1：通过环境变量指定默认用户分配标识 #

在应用的环境变量中设置AZURE_CLIENT_ID为目标用户分配标识的Client ID，这样DefaultAzureCredential会自动使用该标识，无需在代码中显式传递：

var tableUri = new Uri(string.Format("https://{0}.table.core.windows.net/", storageAccountName));
var credential = new DefaultAzureCredential();
services.AddScoped(x => new TableServiceClient(tableUri, credential));

这种方式既保留了DefaultAzureCredential的灵活性，又避免了硬编码Client ID，符合配置化的最佳实践。

方案2：手动遍历用户分配标识并验证权限 #

如果需要在代码中动态选择标识（比如宿主有多个用户分配标识），可以通过Azure Instance Metadata Service (IMDS) 获取当前宿主的所有用户分配标识，然后逐个尝试创建ManagedIdentityCredential并验证访问权限：

using System.Net.Http;
using System.Text.Json;

var tableUri = new Uri(string.Format("https://{0}.table.core.windows.net/", storageAccountName));

// 从IMDS获取用户分配标识列表
var httpClient = new HttpClient();
httpClient.DefaultRequestHeaders.Add("Metadata", "true");
var response = await httpClient.GetAsync("http://169.254.169.254/metadata/identity/info?api-version=2021-02-01");
response.EnsureSuccessStatusCode();
var content = await response.Content.ReadAsStringAsync();
var identityInfo = JsonSerializer.Deserialize<IdentityInfo>(content);

TableServiceClient tableClient = null;
foreach (var userAssignedId in identityInfo.UserAssignedIdentities.Values)
{
    try
    {
        var credential = new ManagedIdentityCredential(userAssignedId.ClientId);
        tableClient = new TableServiceClient(tableUri, credential);
        // 验证权限：尝试执行一个简单操作，比如获取服务属性
        await tableClient.GetPropertiesAsync();
        break; // 找到可用标识，退出循环
    }
    catch (Exception)
    {
        // 标识无权限，继续尝试下一个
        continue;
    }
}

if (tableClient != null)
{
    services.AddScoped(_ => tableClient);
}
else
{
    throw new InvalidOperationException("没有找到具有存储账户访问权限的用户分配标识");
}

// 辅助类用于反序列化IMDS响应
public class IdentityInfo
{
    public Dictionary<string, UserAssignedIdentity> UserAssignedIdentities { get; set; }
}

public class UserAssignedIdentity
{
    public string ClientId { get; set; }
}

注意：这种方式需要确保宿主（如VM、App Service）已启用IMDS访问，且应用有权限读取标识信息。

方案3：通过配置指定用户分配标识 #

可以通过DefaultAzureCredentialOptions显式指定要使用的用户分配标识Client ID，Client ID可以从配置文件（如appsettings.json）读取，而非依赖环境变量：

var tableUri = new Uri(string.Format("https://{0}.table.core.windows.net/", storageAccountName));
var options = new DefaultAzureCredentialOptions
{
    ManagedIdentityClientId = Configuration["Storage:ManagedIdentityClientId"] // 从配置读取
};
var credential = new DefaultAzureCredential(options);
services.AddScoped(x => new TableServiceClient(tableUri, credential));

这种方式的优势是可以结合配置中心（如App Configuration）管理Client ID，更适合复杂的部署场景。

内容的提问来源于stack exchange，提问作者Jake Boomgaarden