Azure中Terraform服务主体权限不足及部署方式咨询

一、解决权限不足问题 #

你遇到的403错误核心原因是：Cloud Application Administrator是Azure AD目录级角色，仅用于管理Azure AD内的应用注册，完全没有订阅/资源组层面的云资源访问权限。要让应用能创建、部署各类云资源，需为其分配订阅或资源组层面的RBAC角色：

1. 选择合适的RBAC角色 #

根据你“广泛创建/部署资源”的需求，推荐两种角色：

• Contributor：订阅/资源组层面角色，拥有除权限分配外的所有资源创建、修改、删除权限，满足常规部署需求。
• Owner：若需要同时管理权限分配（如给其他主体指派角色）可选用，但权限范围更大，建议按需使用。

2. 分配角色的操作步骤 #

• 登录Azure门户，进入目标订阅（或目标资源组）
• 左侧导航栏选择「访问控制(IAM)」
• 点击「添加」→「添加角色分配」
• 在角色列表中搜索并选中「Contributor」（或你需要的角色）
• 点击「成员」→「选择成员」，搜索你的'terraform'应用并选中
• 完成配置后点击「查看 + 分配」

二、当前部署方式的正确性与优化方案 #

1. 当前方式的正确性 #

你用服务主体（应用注册）做Terraform认证的方式是标准且正确的，适合自动化部署、CI/CD流水线等无交互场景。但有一处小问题：
你的azapi provider配置中设置了use_cli = true，这会让azapi优先使用Azure CLI的认证信息，而非你配置的client_id/secret，建议删除该参数，保持和azurerm provider一致的认证逻辑：

provider "azapi" {
  subscription_id = "<subscription_id>"
  client_id = "<client_id>"
  client_secret = "<client_secret>"
  tenant_id = "<tenant_id>"
}

2. 更佳方案推荐 #

（1）用环境变量存储敏感信息

不要将client_secret等敏感信息硬编码到配置文件中，通过环境变量传递更安全：

# Linux/macOS
export ARM_SUBSCRIPTION_ID="<subscription_id>"
export ARM_CLIENT_ID="<client_id>"
export ARM_CLIENT_SECRET="<client_secret>"
export ARM_TENANT_ID="<tenant_id>"

# Windows PowerShell
$env:ARM_SUBSCRIPTION_ID="<subscription_id>"
$env:ARM_CLIENT_ID="<client_id>"
$env:ARM_CLIENT_SECRET="<client_secret>"
$env:ARM_TENANT_ID="<tenant_id>"

之后Terraform provider可简化为：

provider "azurerm" {
  features {}
}

provider "azapi" {
}

Terraform会自动读取这些环境变量，也便于在不同环境间切换。

（2）使用Azure托管标识

如果你的Terraform运行在Azure资源内（如Azure VM、Azure Function、Azure DevOps代理等），可以用托管标识替代服务主体，无需维护client_secret，安全性更高：

• 给运行Terraform的Azure资源启用系统分配或用户分配的托管标识
• 给托管标识分配对应的RBAC角色（如Contributor）
• Terraform provider配置无需client_id/secret，自动使用托管标识认证：

provider "azurerm" {
  features {}
  subscription_id = "<subscription_id>"
  tenant_id = "<tenant_id>"
  use_msi = true
}

（3）Terraform Cloud/Enterprise（团队协作场景）

若为团队协作部署，Terraform Cloud可统一管理认证凭据、状态文件，提供安全的变量存储和协作流程，避免本地管理敏感信息与状态文件的风险。

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