配置Azure存储为Terraform后端时遇403认证失败错误求助

以下是针对该错误的排查和解决方案：

1. 确认服务主体的权限配置 #

• 必须为服务主体分配**存储Blob数据参与者（Storage Blob Data Contributor）**角色，而非普通的"参与者（Contributor）"角色——后者仅拥有资源管理权限，无法访问存储账户内的Blob数据。
• 权限需直接分配到目标存储账户或容器层级，避免依赖资源组继承（RBAC权限可能存在10-15分钟的生效延迟）。
• 用Azure CLI验证权限是否生效：

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

2. 验证认证凭证有效性 #

• 检查本地Azure认证上下文：执行az account show确认当前登录的服务主体与Terraform配置使用的一致。
• 若使用环境变量（ARM_CLIENT_ID、ARM_CLIENT_SECRET、ARM_TENANT_ID、ARM_SUBSCRIPTION_ID），核对变量值无拼写错误，尤其是服务主体密钥（secret）是否包含特殊字符导致转义问题。
• 确认服务主体密钥未过期，若过期则重新生成密钥并更新凭证。

3. 检查存储账户网络限制 #

• 若存储账户启用了防火墙或虚拟网络隔离：
  • 将运行Terraform的机器IP（或CI/CD环境的出口IP）添加到存储账户的允许列表中。
  • 开启"允许受信任的Azure服务访问此存储账户"选项（适用于Azure托管的CI/CD环境）。

4. 核对Terraform后端配置 #

• 确保azurerm后端块参数完全正确，示例正确配置：

  terraform {
    backend "azurerm" {
      storage_account_name = "你的存储账户名"
      container_name       = "tfstate"
      key                  = "terraform.tfstate"
      resource_group_name  = "你的资源组名"
    }
  }
  

• 避免同时混用多种认证方式（如环境变量与Azure CLI登录），优先确保仅使用一种方式完成认证。

5. 检查系统时间同步 #

• 运行Terraform的机器系统时间需与Azure服务器时间保持15分钟以内的误差，否则会导致签名验证失败。同步本地系统到NTP服务器后重试。

6. 确认容器已存在 #

• Terraform不会自动创建存储容器，需提前手动创建：

  az storage container create --name tfstate --account-name <你的存储账户名>
  

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