Github Actions部署Terraform到Azure生产环境遇403权限异常

关于报错中的客户端对象ID问题 #

这是正常现象。SPN（服务主体）存在两个核心标识：

• 应用ID（Client ID）：你在Github Secrets中配置的身份验证标识
• 对象ID（Object ID）：SPN在Azure AD中的唯一实体ID，Azure进行权限校验时会以此识别主体
  所以报错里的对象ID和你配置的应用ID不一致是正常的，无需纠结该点，重点排查权限与身份验证流程。

可能的问题及排查步骤 #

• 权限配置未生效或范围错误

  1. 确认生产环境SPN已被授予Microsoft.Storage/storageAccounts/listKeys/action权限，且权限作用范围覆盖目标存储账户（或其所属资源组/订阅）
  2. 若刚配置权限，需等待5-15分钟让Azure完成权限同步
  3. 验证权限是直接分配给SPN，而非通过组；若通过组，确认SPN已加入对应组

• Github Secrets引用错误

  1. 检查Workflow YML文件中AZURE_CLIENT_ID、AZURE_CLIENT_SECRET、AZURE_TENANT_ID、AZURE_SUBSCRIPTION_ID是否正确引用了生产环境的Secrets，未与开发环境配置混淆
  2. 可在Workflow中添加临时步骤（注意规避敏感信息），验证是否正确加载了生产环境凭据

• Terraform后端配置错误

  1. 确认后端块中的存储账户名称、资源组、订阅ID均为生产环境配置，未复用开发环境参数
  2. 检查后端块是否指定了正确的subscription_id和tenant_id，若未指定，Terraform会使用Azure CLI默认上下文，可能导致凭据错误

• Azure CLI上下文残留

  1. 若Workflow使用Azure CLI登录，需确保每次运行都用生产环境SPN重新登录，避免残留开发环境上下文
  2. 登录步骤明确指定生产环境订阅ID：az account set --subscription ${{ secrets.AZURE_PROD_SUBSCRIPTION_ID }}

• 存储账户网络限制

  1. 检查生产环境存储账户是否开启防火墙或虚拟网络限制，若仅允许特定IP访问，Github Actions的IP可能不在允许列表内
  2. 可临时关闭防火墙测试，若恢复正常，再配置正确的IP范围或服务端点

内容的提问来源于stack exchange，提问作者pieter-jan goeman