3. 多云环境准备与认证管理

当 Terraform 从单云走向多云，第一道门槛往往不是写资源，而是让每个 Provider 都能安全、可复现地完成认证。Terraform 本身不保存云凭证，它通过 Provider 插件调用各云厂商的 API；Provider 的认证方式决定了凭证从哪里来、以什么身份调用、能操作哪些资源。因此，多云环境准备的核心是：为 AWS、Azure、GCP、阿里云分别建立“可验证、可轮换、最小权限”的认证链路，并让同一套 Terraform 代码在不同环境中通过变量和凭据来源切换，而不是把密钥写进代码。

一、Provider 配置的基本结构

每个云厂商在 Terraform 中对应一个 Provider 块。Provider 块负责声明认证参数、区域/订阅/项目等上下文，资源块再引用这些上下文。以 AWS 为例，Provider 可以显式传入 access_key 和 secret_key，但更推荐留空，让 AWS SDK 按标准链自动查找：环境变量、共享凭证文件、IAM 角色、SSO 缓存等。Azure 使用 azurerm Provider，认证依赖订阅 ID、租户 ID、客户端 ID 和客户端密钥，或使用 Azure CLI 登录后的上下文。GCP 使用 google Provider，认证依赖服务账号 JSON 或应用默认凭证（ADC）。阿里云使用 alicloud Provider，认证依赖 AccessKey 或 STS 临时凭证。

provider "aws" {
  region = var.aws_region
  # 不写 access_key/secret_key，走环境变量或 IAM Role
}

provider "azurerm" {
  features {}
  subscription_id = var.azure_subscription_id
  tenant_id       = var.azure_tenant_id
  client_id       = var.azure_client_id
  client_secret   = var.azure_client_secret
}

provider "google" {
  project = var.gcp_project_id
  region  = var.gcp_region
}

provider "alicloud" {
  region = var.aliyun_region
}

这段配置的关键不是“写全参数”，而是让敏感参数从变量或环境注入。变量本身也不应硬编码默认值，而应通过 TF_VAR_ 前缀的环境变量、terraform.tfvars（加入 .gitignore）或 CI/CD 的密钥管理注入。

二、四类主流云的认证方式对比

不同云的认证模型差异较大，理解差异才能设计统一的凭据管理策略。AWS 的 IAM Role 适合在 EC2、EKS、Lambda 等计算环境中免密钥调用；Azure 的 Managed Identity 适合 Azure VM、AKS、Functions；GCP 的 Workload Identity 适合 GKE 和 Cloud Run；阿里云的 RAM Role 适合 ECS 和 ACK。它们的共同点是：把长期密钥替换为短期、可自动轮换的身份令牌。

从表中可以看出，四家云都提供了“角色 + 临时令牌”的路径。多云工程中应优先使用这条路径，把长期 AccessKey 限制在极少数无法使用角色的场景，例如本地开发或部分第三方 CI。对于本地开发，AWS 可用 aws configure sso，Azure 可用 az login，GCP 可用 gcloud auth application-default login，阿里云可用 aliyun configure 生成临时凭证。

三、凭证管理与安全最佳实践

凭证管理的目标可以概括为三点：不落盘、不硬编码、可审计。具体做法包括：

• 环境变量注入：CI/CD 中通过 Secret 管理注入 AWS_ACCESS_KEY_ID、ARM_CLIENT_SECRET、GOOGLE_CREDENTIALS、ALICLOUD_ACCESS_KEY 等，Terraform 运行时读取，不写入仓库。
• 后端加密与状态隔离：远程后端（S3、Azure Blob、GCS、OSS）开启服务端加密和版本控制，状态文件按环境分路径存放，避免跨环境读取敏感输出。
• 最小权限：每个 Provider 使用的身份只授予当前模块需要的 API 权限，例如只允许创建 VPC 和子网，不允许删除数据库。
• 凭证轮换：长期密钥设置 90 天轮换，临时令牌设置 1 小时以内有效期，并在 CI 中通过 OIDC 联合身份直接换取云令牌，彻底消除静态密钥。
• 审计与告警：开启 CloudTrail、Azure Activity Log、GCP Audit Log、阿里云 ActionTrail，对 Terraform 身份的高危操作设置告警。

四、多云认证的验证与排障

配置完成后，不要直接 terraform apply。先用 terraform init 下载 Provider，再用 terraform validate 检查语法，最后用 terraform plan 观察 Provider 是否能成功认证。如果认证失败，常见错误包括：凭证过期、区域不匹配、权限不足、订阅/项目 ID 错误。排障时按“凭证来源 → 身份权限 → 资源上下文”的顺序逐层检查，而不是反复修改代码。

上图把多云认证拆成四层：凭证来源、Terraform 执行层、Provider 参数层、云 API 与安全控制层。实际工程中，这四层要同时成立：凭证来源必须可信，执行层必须隔离状态，Provider 参数必须与环境匹配，云 API 侧必须有审计和最小权限。任何一层缺失，都会导致“本地能跑、CI 失败”或“能创建资源但无法审计”的问题。

五、可复用的环境准备清单

下面这份清单可以直接用于新项目初始化，字段按多云场景设计，不引入无关管理项。

完成以上准备后，可以用一个最小示例验证四家云是否都能认证成功：分别创建各云的一个只读资源或数据源，例如 AWS 的 aws_caller_identity、Azure 的 azurerm_client_config、GCP 的 google_project 数据源、阿里云的 alicloud_account。执行 terraform plan 时，如果四家云都能返回当前身份信息，说明认证链路已经打通。此时再逐步加入网络、计算、存储资源，才能把多云迁移的风险控制在可观测范围内。