基于GitHub Actions与GCP后端的Terraform工作区：多项目认证处理

核心逻辑说明 #

你需要的是同时拥有两个GCP项目的访问权限：一是目标部署环境（A/B/C），二是存储状态的项目D。因为Terraform执行流程是先从D读取状态，再对目标环境的资源进行操作，所以单次部署需要同时能访问这两个项目。

具体实现步骤 #

1. 配置跨项目权限的GCP服务账号 #

• 在项目D中创建一个服务账号，统一管理更方便：
  • 给该账号分配项目D的权限：roles/storage.objectAdmin，用于读写GCS后端状态文件
  • 给该账号分别分配每个环境项目（A/B/C）的权限：根据实际部署需求分配最小权限，比如部署K8s集群就给roles/container.admin，不要直接用editor这类宽泛权限
• 导出该服务账号的JSON密钥，存储为GitHub仓库的机密（Secret），比如命名为GCP_CROSS_PROJECT_SA_KEY

2. GitHub Actions工作流中的认证步骤 #

在执行Terraform命令前完成GCP认证，后续Terraform的后端和Provider会自动复用这个凭证：

- name: Authenticate to GCP
  uses: google-github-actions/auth@v1
  with:
    credentials_json: ${{ secrets.GCP_CROSS_PROJECT_SA_KEY }}

3. Terraform配置优化 #

• 后端配置（绑定项目D的存储桶）：无需额外认证参数，会自动读取上面配置的凭证

terraform {
  backend "gcs" {
    bucket = "tf-state-bucket-in-project-d"
    prefix = "environments/${terraform.workspace}"
  }
}

• GCP Provider配置：通过工作区变量指定目标项目ID，比如在工作区A设置变量gcp_project = "project-a"，Provider直接引用：

provider "google" {
  project = var.gcp_project
  region  = "asia-east1"
}

4. 工作流中切换Terraform工作区 #

在plan/apply前切换到对应环境的工作区，确保操作的是目标环境的状态和资源：

- name: Switch to target workspace
  run: terraform workspace select ${{ inputs.target_env }} || terraform workspace new ${{ inputs.target_env }}

这里的target_env可以通过工作流的手动输入参数、分支名映射等方式传入，比如手动触发时选择环境A，就传入A。

安全优化建议 #

• 定期轮换服务账号密钥，降低泄露风险
• 在工作流中添加Terraform状态锁定检查，防止多人同时操作同一环境的状态
• 给服务账号的权限做细分，比如项目A只需要创建云函数，就分配roles/cloudfunctions.developer而非宽泛的管理员权限

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