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

发布于:2025-07-22 ⋅ 阅读:(17) ⋅ 点赞:(0)

自动化与安全 - 将 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 文件:


网站公告

今日签到

点亮在社区的每一天
去签到