App Service中Docker容器使用Node SDK无法访问KeyVault问题

问题根因 #

你遇到的问题是Azure App Service多容器（Docker Compose）部署场景的默认限制：App Service仅会自动将托管身份相关的系统环境变量（MSI_ENDPOINT、MSI_SECRET等）注入到Docker Compose配置中services节点下定义的第一个容器。如果你运行业务代码的容器不是第一个服务，自然无法获取到托管身份认证所需的环境变量，DefaultAzureCredential就会跳过托管身份认证链路，降级尝试Azure CLI等其他认证方式，最终触发登录报错。

解决方案 #

• 方案1：调整Docker Compose的服务排序，将需要访问Key Vault等Azure资源的业务容器放在services下的第一个位置，无需手动配置环境变量，App Service会自动完成MSI变量注入。
• 方案2：如果无法调整服务排序，手动在需要使用托管身份的服务配置中显式透传环境变量，配置示例如下：

services:
  # 其他不依赖托管身份的服务可以放在前面
  other-service:
    image: xxx:xxx
  # 你的Node.js业务服务
  node-app:
    image: your-node-image:tag
    environment:
      - MSI_ENDPOINT=${MSI_ENDPOINT}
      - MSI_SECRET=${MSI_SECRET}

额外检查项 #

1. 权限校验：
   • 如果使用Key Vault经典访问策略模式，确认App Service的托管身份已被授予机密的Get、List权限，注意不要混淆访问策略与Azure RBAC权限配置。
   • 如果使用Key Vault RBAC模式，确认托管身份已被分配Key Vault Secrets User等包含机密读取权限的角色。
2. 用户托管身份适配：如果使用的是用户分配托管身份而非系统托管身份，需要在实例化DefaultAzureCredential时显式传入托管身份的客户端ID，代码修改如下：

const keyVaultClient = new SecretClient(
  `https://<key-vault-name>.vault.azure.net`,
  new DefaultAzureCredential({
    managedIdentityClientId: "<用户托管身份客户端ID>"
  })
)

3. 不要通过在容器内安装Azure CLI的方式解决认证问题，该操作会导致DefaultAzureCredential优先尝试CLI认证链路，反而绕开了更安全的托管身份认证路径，属于错误的绕路方案。

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