Azure环境下Terraform状态文件敏感数据防护方案咨询

一、修复当前Terraform Backend配置的核心问题 #

注意：你的Backend配置中直接引用data.azurerm_key_vault_secret的值是无效的——Terraform在初始化Backend时，还未加载任何data资源或Provider配置，会导致初始化失败。正确的做法是通过环境变量或Terraform变量传递Backend所需的SPN凭据：

修正后的Backend配置示例 #

terraform {
  required_providers {
    confluent = {
      source  = "confluentinc/confluent"
      version = "1.77.0"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.95"
    }
  }

  backend "azurerm" {
    resource_group_name  = "my_resource_group"
    storage_account_name = "mystorageacc"
    container_name       = "terraform"
    key                  = "connectors/ccpre.tfstate"
    # 从环境变量读取凭据，避免硬编码或引用未初始化的资源
    client_id       = "${envARM_CLIENT_ID}"
    client_secret   = "${envARM_CLIENT_SECRET}"
    tenant_id       = "${envARM_TENANT_ID}"
    subscription_id = "${envARM_SUBSCRIPTION_ID}"
  }
}

provider "azurerm" {
  features {}
  # Provider凭据同样从环境变量读取
  client_id       = var.arm_client_id
  client_secret   = var.arm_client_secret
  tenant_id       = var.arm_tenant_id
  subscription_id = var.arm_subscription_id
}

provider "confluent" {
  cloud_api_key    = data.azurerm_key_vault_secret.confluent_cloud_api_key.value
  cloud_api_secret = data.azurerm_key_vault_secret.confluent_cloud_api_secret.value
}

# 定义变量（可选，也可直接用环境变量传递给Provider）
variable "arm_client_id" {
  type        = string
  sensitive   = true
  description = "Azure SPN Client ID"
  default     = "${envARM_CLIENT_ID}"
}

# 其他变量（arm_client_secret/arm_tenant_id/arm_subscription_id）定义同理

在GitHub Action中，从Azure KeyVault读取凭据并设置为环境变量：

- name: Azure Login
  uses: azure/login@v1
  with:
    creds: ${{ secrets.AZURE_CREDENTIALS }}

- name: Fetch Secrets from KeyVault
  id: get-secrets
  uses: azure/get-keyvault-secrets@v1
  with:
    keyvault: "your-keyvault-name"
    secrets: |
      arm-client-id
      arm-client-secret
      arm-tenant-id
      arm-subscription-id

- name: Terraform Init
  run: terraform init
  env:
    ARM_CLIENT_ID: ${{ steps.get-secrets.outputs.arm-client-id }}
    ARM_CLIENT_SECRET: ${{ steps.get-secrets.outputs.arm-client-secret }}
    ARM_TENANT_ID: ${{ steps.get-secrets.outputs.arm-tenant-id }}
    ARM_SUBSCRIPTION_ID: ${{ steps.get-secrets.outputs.arm-subscription-id }}

二、Azure Blob Storage层面的tfstate安全强化方案 #

1. 启用服务器端加密（SSE） #

Azure Blob Storage默认已启用Microsoft托管密钥的服务器端加密，所有存储的tfstate文件会自动加密。若需更高控制权，可切换为客户托管密钥（CMK）：

• 进入Azure Portal的存储账户 -> 加密 -> 选择"客户托管密钥"
• 关联Azure KeyVault中的密钥，确保存储账户拥有访问该KeyVault密钥的权限

2. 启用Blob版本控制与软删除 #

防止tfstate文件被误删或恶意篡改：

• 在存储账户的目标容器 -> 数据保护 -> 启用"版本控制"和"软删除"
• 设置软删除保留期（如30天），便于恢复误删的状态文件

3. 最小权限原则配置RBAC #

限制访问tfstate存储容器的身份权限：

• 为GitHub Action使用的SPN或托管标识，仅分配Storage Blob Data Contributor角色，且仅针对tfstate所在的容器（而非整个存储账户）
• 避免使用Storage Account Contributor等过度权限的角色

4. 客户端级别的tfstate加密（可选） #

若需对tfstate内容进行端到端加密（即使在Blob存储中也无法读取明文），可结合Azure KeyVault使用Terraform客户端加密：

• 在Azure KeyVault中生成并存储一个AES密钥
• Terraform初始化时，通过TF_ENCRYPTION_KEY环境变量传递该密钥（从KeyVault获取），Terraform会自动加密tfstate内容后再上传到Blob

三、替代方案（兼容现有工作流） #

如果需要更简化的状态管理，可考虑：

• Terraform Cloud：提供内置的状态加密、版本控制和访问控制，支持GitHub Action集成，无需手动管理Blob存储
• Azure DevOps Terraform任务：Azure DevOps的Terraform扩展自带状态存储管理，可直接关联Azure Blob并启用加密

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