GitHub Actions + AWS Role Chaining：值得进行的安全升级

Source: Dev.to

Introduction

随着一年即将结束，我在反思并有意识地提升自己的安全知识。
自从加入 Muzz 以来，我一直在处理跨多个 AWS 账户的大规模系统、生产关键的流水线以及不能容忍安全松懈的基础设施。其中最有价值的经验之一是 GitHub Actions 中的 AWS 角色链。起初它可能看起来很复杂，但一旦弄懂，你会发现：

“是的……这才是 CI/CD 应该的工作方式。”

Problems with Static AWS Credentials

传统上，CI/CD 流水线通过在 GitHub Secrets 中存储 AWS_ACCESS_KEY_ID 和 AWS_SECRET_ACCESS_KEY 等凭证来访问 AWS。虽然可行，但会带来若干问题：

• 长期有效的凭证存放在 GitHub 中
• 难以安全地轮换
• 为了“以防万一”而过度授权的策略
• 环境之间缺乏明确的信任边界
• 随着组织规模扩大，风险也随之上升

随着团队壮大、环境增多（共享、开发、预发布、生产），这种做法无法安全扩展。

Moving to OIDC and Role Chaining

我们将静态密钥改为使用：

• GitHub Actions OpenID Connect (OIDC) – 详见我之前的博客文章。
• 带有信任策略的 IAM 角色
• 短期 AWS 凭证
• 用于环境隔离的角色链

此变更带来了多项好处：

• GitHub 中不再存储 AWS 密钥
• 凭证仅在作业运行时颁发
• 访问权限严格限定且有时间限制

What Is AWS Role Chaining?

角色链指的是 GitHub Actions 首先 假设一个基础角色（通常位于共享的 AWS 账户），随后再 假设目标角色 以对应具体环境（开发、生产等）。

可以把它想象成机场安检：

1. GitHub 通过主入口（共享角色）。
2. 然后被引导到正确的航站楼（开发/生产角色）。

没有自由漫游，也没有捷径——每一步都必须明确受信任。

How It Works

1. 在目标 AWS 账户中 配置 GitHub Actions OIDC 提供商。
2. 创建一个基础角色，其信任策略允许 GitHub OIDC 主体。
3. 创建环境专属角色，信任该基础角色。
4. 在工作流中使用官方 AWS Action 并设置 role‑chaining: true（或回退到 aws sts assume-role）。

Example Configuration

# .github/workflows/deploy.yml
- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::ACCOUNT_ID:role/target-role
    role-chaining: true
    aws-region: eu-west-2

如果你更喜欢手动方式：

aws sts assume-role \
  --role-arn arn:aws:iam::ACCOUNT_ID:role/target-role \
  --role-session-name github-actions-session

Why Adopt This Pattern?

安全不是可以“后期添加”的东西；它应从第一天起就嵌入到工作流中。使用 GitHub Actions 与 AWS 角色链：

• 消除 CI/CD 中的长期密钥
• 在环境之间提供清晰的信任边界
• 提升审计能力，让生产部署更有信心

如果你仍在 CI/CD 中使用长期 AWS 密钥，这无疑是最干净的升级之一。

希望这能帮助各位构建者以更高的信心、更低的风险交付。如果有任何问题，欢迎留言讨论。