Azure部署时获取Service Bus连接字符串及权限问题咨询

方案1：资源模板内直接获取Service Bus密钥注入Function配置 #

直接用Azure资源模板的listKeys内置函数就能在部署阶段直接读取Service Bus的访问密钥，不需要额外的CLI操作，Bicep示例如下，ARM模板写法逻辑完全一致：

// 定义已部署的Service Bus命名空间引用
resource serviceBusNamespace 'Microsoft.ServiceBus/namespaces@2021-11-01' existing = {
  name: '<你的Service Bus命名空间名称>'
  resource authRule 'authorizationRules' existing = {
    name: 'RootManageSharedAccessKey'
  }
}

// 部署Function App时直接把连接字符串写入应用配置
resource functionApp 'Microsoft.Web/sites@2022-03-01' = {
  name: '<你的Function名称>'
  kind: 'functionapp'
  location: resourceGroup().location
  properties: {
    serverFarmId: appServicePlan.id
    siteConfig: {
      appSettings: [
        // 直接通过listKeys获取连接字符串
        {
          name: 'ServiceBusNamespaceConnectionString'
          value: serviceBusNamespace::authRule.listKeys().primaryConnectionString
        }
        // 其他配置项...
      ]
    }
  }
}

部署完成后Function可以直接读取环境变量ServiceBusNamespaceConnectionString使用，和你原来用连接字符串的代码完全兼容，不需要做任何代码修改。

方案2：修复DefaultAzureCredential权限问题（更推荐，无需管理密钥） #

你遇到的权限报错是因为Function的托管身份没有被分配Service Bus的发送权限，这套方案不需要处理任何连接字符串，安全性更高，操作步骤如下：

1. 开启Function的系统托管身份：在资源模板中给Function App添加托管身份配置，Bicep示例：

resource functionApp 'Microsoft.Web/sites@2022-03-01' = {
  name: '<你的Function名称>'
  kind: 'functionapp'
  location: resourceGroup().location
  identity: {
    type: 'SystemAssigned' // 开启系统分配托管身份
  }
  // 其他配置...
}

2. 给托管身份分配Service Bus发送权限：在模板中添加角色分配，给Function的托管身份分配Azure Service Bus 数据发送者角色，范围可以是整个Service Bus命名空间或者指定队列：

// Service Bus数据发送者角色的内置ID
var serviceBusSenderRole = subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '69a216f7-9e90-481d-ac13-cea795730835')

resource serviceBusSendRoleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(serviceBusNamespace.id, functionApp.id, serviceBusSenderRole)
  scope: serviceBusNamespace
  properties: {
    roleDefinitionId: serviceBusSenderRole
    principalId: functionApp.identity.principalId
    principalType: 'ServicePrincipal'
  }
}

3. 代码无需大幅修改：你原来写的DefaultAzureCredential代码不用改，部署到Azure后DefaultAzureCredential会自动读取Function的系统托管身份凭证，本地开发时会自动读取你本地VS/Azure CLI登录的账号凭证，只要本地账号也有对应Service Bus的发送权限就能正常调试。
   DefaultAzureCredential的逻辑是按优先级依次尝试可用的身份源：本地开发环境优先取VS/VS Code/Azure CLI的登录身份，部署到Azure后优先取托管身份的凭证，全程不需要你手动维护任何密钥。

两个方案都可以完全通过资源模板实现全自动化部署，不需要额外的后置CLI操作，推荐优先用方案2，避免密钥泄露和密钥轮换的额外运维成本。

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