📚 课程目录第3章 Provider与云平台认证管理

3. Provider与云平台认证管理

Terraform 本身并不直接调用云 API，它通过 Provider 插件把 HCL 资源声明翻译成对应云平台的 REST 调用。因此，Provider 的配置与认证方式，决定了 Terraform 能否正确、安全地访问目标云环境。在企业场景中，一个工程往往同时管理阿里云、AWS、腾讯云甚至 Kubernetes 集群，Provider 的组织方式与凭证管理策略，直接关系到代码的可维护性和安全性。

Provider 的声明与版本约束

Provider 通过 required_providers 块声明，并配合 required_version 约束 Terraform 核心版本。版本约束使用与 npm 类似的语义化版本语法：~> 5.0 表示允许 5.x 的最新补丁版本，>= 4.0, < 6.0 表示区间约束。企业实践中应避免使用 latest 或完全不加约束，否则一次 terraform init 就可能因 Provider 升级引入破坏性变更。

terraform {
  required_version = ">= 1.5.0, < 2.0.0"

  required_providers {
    alicloud = {
      source  = "aliyun/alicloud"
      version = "~> 1.220"
    }
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.40"
    }
  }
}

版本约束应写入版本控制，并配合 .terraform.lock.hcl 锁定文件一起提交。锁定文件记录了每个 Provider 的精确版本与校验和，保证团队所有成员和 CI 流水线使用完全一致的插件，这是可复现构建的基础。

多 Provider 与别名机制

当同一云平台需要管理多个账号、多个地域，或需要跨账号复制资源时，就要用到 Provider 别名。默认 Provider 不带 alias，别名 Provider 则通过 alias 参数区分。资源通过 provider 元参数显式指定使用哪个别名实例。

provider "alicloud" {
  region = "cn-hangzhou"
}

provider "alicloud" {
  alias  = "beijing"
  region = "cn-beijing"
}

resource "alicloud_vpc" "hz" {
  vpc_name   = "vpc-hangzhou"
  cidr_block = "10.0.0.0/16"
}

resource "alicloud_vpc" "bj" {
  provider   = alicloud.beijing
  vpc_name   = "vpc-beijing"
  cidr_block = "10.1.0.0/16"
}

别名机制同样适用于跨账号场景：为生产账号和测试账号各配置一个别名 Provider，通过不同的 AccessKey 或 AssumeRole 配置隔离权限。需要注意的是，别名 Provider 的认证信息应来自变量或环境变量，而不是硬编码在配置中。

认证凭证的传递方式

Provider 获取凭证的优先级通常为：显式配置参数 > 环境变量 > 共享凭证文件 > 实例元数据（如 ECS RAM 角色、EC2 Instance Profile）。企业环境应优先使用实例元数据或 OIDC 联合身份，避免长期 AccessKey 落盘。

方式	典型场景	安全等级
环境变量	本地开发、CI 临时注入	中
共享凭证文件	开发者本机多账号切换	中低
实例元数据 / RAM 角色	ECS、EC2 上运行的 Runner	高
OIDC 联合身份	GitHub Actions、GitLab CI	高

以阿里云为例，环境变量方式为 ALICLOUD_ACCESS_KEY 与 ALICLOUD_SECRET_KEY；AWS 则为 AWS_ACCESS_KEY_ID 与 AWS_SECRET_ACCESS_KEY。在 CI 中，这些值应通过 Secret 注入，而不是写进仓库。

切勿将 AccessKey、SecretKey 或 terraform.tfstate 提交到 Git。State 文件中可能包含明文凭证和资源属性，应使用远端后端（OSS、S3）并开启加密与访问控制。

多云认证的最佳实践

企业多云环境建议遵循以下原则：第一，按环境拆分目录或工作区，每个环境使用独立的 Provider 配置和凭证；第二，生产环境凭证只授予最小必要权限，通过 RAM Policy 或 IAM Policy 限定到具体资源；第三，CI/CD 中使用 OIDC 或临时 STS Token，避免长期密钥；第四，所有 Provider 版本统一约束并提交锁定文件；第五，敏感变量使用 sensitive = true 标记，防止在 plan 输出中泄露。

variable "alicloud_access_key" {
  type      = string
  sensitive = true
}

provider "alicloud" {
  access_key = var.alicloud_access_key
  secret_key = var.alicloud_secret_key
  region     = var.region
}

下面这张图展示了多 Provider 配置中，凭证来源、Provider 实例与目标云账号之间的对应关系，以及别名 Provider 如何将资源路由到不同地域或账号。

图中左侧是凭证来源，中间是 Provider 实例（含默认与别名），右侧是目标云环境。资源通过 provider 元参数绑定到具体实例，从而决定请求发往哪个地域或账号。底部强调版本锁定与敏感变量标记，这两点与认证安全同等重要。

实操检查清单

所有 Provider 是否声明了 source 与 version 约束？
.terraform.lock.hcl 是否已提交到版本控制？
是否使用别名 Provider 隔离多账号、多地域？
凭证是否来自环境变量、实例角色或 OIDC，而非硬编码？
敏感变量是否标记 sensitive = true？
State 后端是否启用加密与访问控制？