使用User Assigned Managed Identity本地运行Azure Function遇认证问题求助

你在local.settings.json中明确指定了ServiceBusConnection__credential": "managedIdentity"，这会强制Service Bus绑定仅使用ManagedIdentityCredential进行认证。而本地开发环境不存在Azure托管标识的元数据端点（报错中的169.254.169.254是Azure VM专属的托管标识服务地址），因此认证失败，且不会触发DefaultAzureCredential的其他 fallback 认证选项（比如你期望的VS登录账号）。

方案一：本地切换为DefaultAzureCredential（复用VS登录账号） #

修改local.settings.json的配置，将credential值改为default，让绑定使用DefaultAzureCredential自动尝试VS的共享令牌缓存凭据：

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet",
    "ServiceBusConnection__clientId": "<my_uami_client_id>", // 注意补全缺失的闭合引号
    "ServiceBusConnection__credential": "default",
    "ServiceBusConnection__fullyQualifiedNamespace": "my-service-bus.servicebus.windows.net"
  }
}

同时需要确保你的VS登录账号拥有目标Service Bus队列的Azure Service Bus Data Receiver权限（和之前给用户托管标识配置的权限一致即可）。

方案二：使用Azure CLI凭据辅助本地开发 #

如果不想修改配置，可先通过Azure CLI登录你的账号：

az login

同样需要将ServiceBusConnection__credential改为default，让DefaultAzureCredential拾取CLI的认证凭据。

方案三：区分本地与云端配置 #

可以通过Azure Functions的配置变换机制，或者维护两份local.settings.json文件：

• 云端部署时保留managedIdentity配置
• 本地开发时使用default配置
  避免每次发布都手动修改配置。

额外建议 #

将你的Azure.Identity包版本从1.8.0升级到较新的稳定版本（如1.12.0），部分旧版本存在DefaultAzureCredential fallback逻辑的已知问题。

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