通过管理组分配Azure RBAC角色的差异及Terraform初始化403问题

1. 权限是否足够创建Terraform状态文件？ #

Terraform用Azure Blob存储状态时，核心需要对存储账户、容器的写入/创建权限。你手里的Storage Blob Data Owner权限本身完全够用——这个角色拥有Blob存储的全部权限，包括创建容器、写入状态文件；Contributor也能管理存储账户资源。但要盯两个点：

• 这些权限有没有覆盖到目标存储账户/容器？管理组继承的权限得确保存储账户所在的订阅/资源组在管理组的层级范围内，不然继承不到。
• 要是首次初始化，Terraform得先创建容器（没提前建的话），这时候除了Blob数据权限，还得有存储账户的容器创建权限——Contributor包含这个，但如果存储账户设了只读锁，直接就被拦了。

2. 管理组分配RBAC的特殊限制 #

管理组层级的RBAC会向下继承到所有子管理组、订阅、资源组和资源，但有几个容易踩坑的限制：

• 继承延迟：从管理组分配角色后，权限同步到下层资源可能要几分钟甚至更久，刚分配完就跑操作很容易碰到权限没生效的情况。
• 拒绝分配/权限边界：如果订阅、资源组或者存储账户上有拒绝分配（Deny Assignment），或者给服务主体设了权限边界（Permission Boundary），会直接覆盖继承的允许权限，导致403。
• 管理组范围不匹配：要是目标存储账户的订阅不在这个管理组的子层级里，权限根本传不下去——先确认订阅归属的管理组对不对。

3. 具体排查步骤 #

• 验证权限覆盖：用Azure CLI跑下面的命令，查服务主体对目标存储账户的有效权限：

  az role assignment list --assignee <服务主体ID> --scope /subscriptions/<订阅ID>/resourceGroups/<资源组ID>/providers/Microsoft.Storage/storageAccounts/<存储账户名> --all
  

  得能看到从管理组继承来的Storage Blob Data Owner和Contributor角色。
• 检查存储账户状态：确认存储账户没设资源锁，要是容器已经存在，也得检查有没有特殊访问策略（比如私有容器但没正确授权）。
• 核对OIDC认证上下文：在Github Actions工作流里加个步骤，打印认证后的订阅ID和权限：

  - name: 检查Azure上下文
    run: |
      az account show
      az role assignment list --assignee $(az ad sp show --id ${{ secrets.AZURE_CLIENT_ID }} --query id -o tsv) --all
  

  确认当前上下文的订阅是存储账户所在的订阅，权限也加载正确了。
• 手动测试Blob操作：在工作流里加个手动传Blob的步骤，验证能不能写入存储账户：

  az storage blob upload --account-name <存储账户名> --container-name <容器名> --name test.txt --content "test" --auth-mode login
  

  要是这个操作也失败，就是Blob权限的问题；要是成功，再检查Terraform后端配置的存储账户名、容器名、订阅ID是不是都对得上。

4. 常见修复方案 #

• 要是继承延迟的问题，等10-15分钟再重新跑工作流。
• 存在拒绝分配的话，找到对应的规则调整（比如删掉针对这个服务主体的拒绝策略）。
• 要是权限边界限制了服务主体，要么扩大权限边界范围，要么直接在资源层级补分配所需权限。
• 要是Terraform后端的容器还没建，确保服务主体有创建容器的权限（Contributor已经包含，但存储账户锁着的话不行）。

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