自动化与安全 - 将 Terraform 集成到 CI/CD
CI/CD 中 Terraform 的标准工作流
一个成熟的、基于 Git 的 Terraform 工作流通常遵循以下模式,这个模式的核心是通过 Pull Request (PR) 来审查和批准变更。
当开发者创建一个指向
main
分支的 PR 时:- CI 流水线被触发。
- 自动运行
terraform init
(初始化),fmt -check
(格式检查),validate
(语法检查)。 - (安全扫描) 自动运行
tfsec
等工具,扫描代码中是否存在已知的安全配置风险。 - (规划) 自动运行
terraform plan
,生成变更计划。 - (审查) 将
plan
的结果摘要,以评论的形式自动发布到 PR 页面,供团队成员审查。审查者可以清晰地看到这次变更将要“创建”、“修改”或“销毁”哪些资源。 - (审批) 只有当所有自动化检查(包括安全扫描)都通过,并且得到了团队成员的“Approve”后,这个 PR 才允许被合并。
当 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 请求一个临时的、短期的身份凭证,而无需存储任何长期密钥。
- 设置(一次性):
- 在 AWS IAM 中,创建一个 OIDC 身份提供商,并将其与 GitHub 关联。
- 创建一个 IAM 角色,该角色拥有执行 Terraform 所需的权限(例如,管理 EC2 和 S3 的权限)。
- 编辑该角色的信任策略,允许来自你特定 GitHub 仓库的特定分支的 Actions 来代入 (Assume) 这个角色。
这个设置过程较为详细,你可以参考 GitHub 官方文档 进行配置。
2. 创建 GitHub Actions 工作流文件
在你的 terraform-101
项目中,创建 .github/workflows/terraform.yml
文件: