自动化与安全 - 将 Terraform 集成到 CI/CD

自动化与安全 - 将 Terraform 集成到 CI/CD

---

CI/CD 中 Terraform 的标准工作流

一个成熟的、基于 Git 的 Terraform 工作流通常遵循以下模式，这个模式的核心是通过 Pull Request (PR) 来审查和批准变更。

1. 当开发者创建一个指向 main 分支的 PR 时:

   • CI 流水线被触发。
   • 自动运行 terraform init (初始化), fmt -check (格式检查), validate (语法检查)。
   • (安全扫描) 自动运行 tfsec 等工具，扫描代码中是否存在已知的安全配置风险。
   • (规划) 自动运行 terraform plan，生成变更计划。
   • (审查) 将 plan 的结果摘要，以评论的形式自动发布到 PR 页面，供团队成员审查。审查者可以清晰地看到这次变更将要“创建”、“修改”或“销毁”哪些资源。
   • (审批) 只有当所有自动化检查（包括安全扫描）都通过，并且得到了团队成员的“Approve”后，这个 PR 才允许被合并。

2. 当 PR 被合并到 main 分支时:

   • 另一条 CI/CD 流水线（或同一流水线的另一部分）被触发。
   • 它会检出最新的 main 分支代码。
   • (应用) 自动运行 terraform apply，将之前在 PR 中已被审查和批准的计划，正式应用到真实的基础设施上。

这个流程确保了每一次基础设施的变更都是经过版本控制、自动化验证、人工审查和自动执行的，最大限度地保障了变更的可靠性和安全性。

实践：在 GitHub Actions 中实现完整工作流

我们将创建一个 GitHub Actions 工作流来实现上述流程。

1. 安全地配置 AWS 凭证

首先，我们需要让 GitHub Actions 的 Runner 能够安全地获取操作 AWS 的权限。我们绝不能将长期的 Access Key/Secret Key 直接存储在 GitHub Secrets 中。

最佳实践是使用 OpenID Connect (OIDC)：

• 理念: GitHub Actions 可以向 AWS 请求一个临时的、短期的身份凭证，而无需存储任何长期密钥。
• 设置（一次性）:
  1. 在 AWS IAM 中，创建一个 OIDC 身份提供商，并将其与 GitHub 关联。
  2. 创建一个 IAM 角色，该角色拥有执行 Terraform 所需的权限（例如，管理 EC2 和 S3 的权限）。
  3. 编辑该角色的信任策略，允许来自你特定 GitHub 仓库的特定分支的 Actions 来代入 (Assume) 这个角色。

这个设置过程较为详细，你可以参考 GitHub 官方文档 进行配置。

2. 创建 GitHub Actions 工作流文件

在你的 terraform-101 项目中，创建 .github/workflows/terraform.yml 文件：