Terraform CI/CD管道中Azure服务主体安全管理最佳实践问询

方案对比：管道机密变量 vs Azure Key Vault #

1. 管道变量中的机密 #

• 优势：配置简单，直接在CI/CD平台（如Azure DevOps、GitHub Actions）内设置，无需额外依赖，适合小型项目或快速验证场景。
• 劣势：
  • 机密分散存储，跨项目/管道复用成本高；
  • 权限控制粒度粗，大多只能到管道级别；
  • 审计能力有限，难以追踪机密的使用和变更轨迹。

2. Azure Key Vault #

• 优势：
  • 集中管理所有Azure相关机密，跨项目/管道复用更高效；
  • 基于Azure RBAC实现细粒度权限控制，可精确限定谁能读取或管理机密；
  • 集成Azure Monitor提供完整审计日志，满足合规溯源需求；
  • 支持自动轮换机密，降低长期使用带来的泄露风险。
• 劣势：初期需要配置Key Vault和CI/CD管道的集成，有一定前置工作量。

结论：如果你的场景要求高安全性、可扩展性和合规性，优先选择Azure Key Vault方案。

Azure Key Vault集成Terraform CI/CD工作流的最佳实践与准则 #

1. 准备Key Vault基础配置 #

• 创建Key Vault实例时，务必启用软删除和清除保护，防止机密被意外删除或恶意恢复；
• 在Key Vault中按规范存储Terraform所需的服务主体凭据：
  • 将client_id（服务主体应用ID）、client_secret（服务主体密钥）、subscription_id、tenant_id分别创建为机密（Secret）；
  • 采用清晰的命名规则，例如terraform-dev-sp-client-id、terraform-prod-sp-client-secret，方便区分环境和用途。

2. 配置CI/CD管道的访问权限 #

• 为CI/CD管道的执行身份（比如Azure DevOps的服务连接、GitHub Actions的Azure服务主体）分配Key Vault的Key Vault Secrets User角色，仅授予机密读取权限（遵循最小权限原则）；
• 绝对避免使用全局管理员或高权限角色，严格限制访问范围。

3. Terraform与Key Vault的集成方式 #

方式一：通过Terraform数据源读取机密

直接在Terraform代码中引用Key Vault的机密，无需硬编码：

# 读取Key Vault中的服务主体ID
data "azurerm_key_vault_secret" "sp_client_id" {
  name         = "terraform-sp-client-id"
  key_vault_id = "/subscriptions/<your-sub-id>/resourceGroups/<your-rg>/providers/Microsoft.KeyVault/vaults/<your-kv-name>"
}

# 读取Key Vault中的服务主体密钥
data "azurerm_key_vault_secret" "sp_client_secret" {
  name         = "terraform-sp-client-secret"
  key_vault_id = "/subscriptions/<your-sub-id>/resourceGroups/<your-rg>/providers/Microsoft.KeyVault/vaults/<your-kv-name>"
}

provider "azurerm" {
  features {}

  subscription_id = "<your-sub-id>" # 也可从Key Vault读取
  tenant_id       = "<your-tenant-id>" # 也可从Key Vault读取
  client_id       = data.azurerm_key_vault_secret.sp_client_id.value
  client_secret   = data.azurerm_key_vault_secret.sp_client_secret.value
}

方式二：CI/CD管道注入环境变量

在CI/CD步骤中先从Key Vault拉取机密，注入为环境变量，Terraform会自动识别Azure的标准环境变量（ARM_CLIENT_ID、ARM_CLIENT_SECRET等）：
以Azure DevOps管道为例：

- task: AzureKeyVault@2
  inputs:
    azureSubscription: '<你的Azure服务连接>'
    KeyVaultName: '<你的Key Vault名称>'
    SecretsFilter: 'terraform-sp-client-id,terraform-sp-client-secret,terraform-sp-subscription-id,terraform-sp-tenant-id'
    RunAsPreJob: false

- script: |
    terraform init
    terraform plan
    terraform apply -auto-approve
  env:
    ARM_CLIENT_ID: $(terraform-sp-client-id)
    ARM_CLIENT_SECRET: $(terraform-sp-client-secret)
    ARM_SUBSCRIPTION_ID: $(terraform-sp-subscription-id)
    ARM_TENANT_ID: $(terraform-sp-tenant-id)

4. 安全合规准则 #

• 定期轮换服务主体密钥和Key Vault中的机密，可通过Azure自动化账户配置自动轮换规则；
• 启用Key Vault的审计日志，将日志转发到Azure Log Analytics，定期审查访问记录；
• 限制Key Vault的网络访问，仅允许CI/CD管道的IP范围或Azure服务端点（如Azure DevOps托管代理IP）访问；
• 确保Terraform状态文件（如存储在Azure Blob）启用加密和严格的权限控制，避免敏感数据泄露；
• 定期审查CI/CD执行身份的权限，移除不必要的访问权限。

5. 可扩展性优化 #

• 为开发、测试、生产等不同环境创建独立的Key Vault实例，实现环境隔离；
• 使用Azure管理组和RBAC批量管理多个Key Vault的权限，降低维护成本；
• 结合Azure Policy强制Key Vault的安全配置（如必须启用软删除、清除保护），确保所有实例遵循统一标准。

内容的提问来源于stack exchange，提问作者Salvatore Calla'