使用Azure DevOps自托管Agent执行Terraform时遭遇403错误求助

一、先核对存储账户的网络配置细节 #

• 检查存储账户的防火墙和虚拟网络设置：一定要确认有没有勾选「允许受信任的Microsoft服务访问此存储账户」——Terraform刷新状态时可能依赖微软托管的服务组件，没开这个的话，哪怕子网在白名单里也会被拦。
• 验证子网的服务端点配置：确保子网已经启用Microsoft.Storage服务端点，而且存储账户白名单里的子网资源ID完全正确，别写错字符或资源组名称。
• 确认存储账户的默认网络访问策略：如果设成了「拒绝」，就得保证所有访问来源都在允许列表里，包括Agent所在子网和必要的服务例外。

二、排查Terraform状态存储的权限配置 #

• 如果Terraform状态文件存在这个存储账户的容器里，先查执行terraform plan的Agent身份（比如VM的系统分配标识/用户分配标识）有没有存储Blob数据参与者权限：
  • 用命令查当前权限：az role assignment list --assignee <agent-identity-id> --scope <storage-account-resource-id>
  • 权限不够的话直接加：az role assignment create --assignee <agent-identity-id> --role "Storage Blob Data Contributor" --scope <storage-account-resource-id>
• 确认Terraform配置里用的身份验证方式：优先用MSI（托管标识），别用过时的存储账户密钥——密钥过期或权限变更大概率会导致403。

三、自建Ubuntu VM Agent的额外排查点 #

• 检查VM网卡的子网关联：用az network nic show --name <nic-name> --resource-group <rg-name>确认subnetId和存储账户白名单里的子网完全匹配，别插错子网了。
• 在VM上直接测试存储访问：执行az storage container list --account-name <storage-account-name>，如果也返回403，说明是网络/权限问题，和Terraform配置无关；如果能正常返回，再查Terraform的环境变量或状态配置。
• 核对NSG出站规则：确保没有阻止到存储服务的443端口流量，目标服务标签选Storage.<你的区域>就行。

四、临时定位问题的验证方案 #

• 临时把存储账户的网络访问改成「允许所有网络」，跑一遍terraform plan，如果正常，说明问题确实在网络白名单或权限配置；如果还是403，查Terraform状态文件的配置或身份验证信息。
• 临时给Agent身份分配存储账户所有者权限测试，排除权限粒度不够的问题，之后再调回最小必要权限。

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