GitHub Actions + AWS Role Chaining: 만들 가치가 있는 보안 업그레이드
Source: Dev.to
Introduction
연말이 다가오면서 저는 보안 지식을 되돌아보고 의도적으로 향상시키고 있습니다.
Muzz에 합류한 이후, 여러 AWS 계정에 걸쳐 대규모로 운영되는 시스템, 프로덕션에 필수적인 파이프라인, 그리고 보안이 느슨해질 수 없는 인프라와 작업해 왔습니다. 가장 가치 있는 교훈 중 하나는 GitHub Actions에서의 AWS 역할 체이닝이었습니다. 처음엔 복잡해 보일 수 있지만, 이해하고 나면 다음과 같이 느끼게 됩니다:
“네… 이게 바로 CI/CD가 작동해야 하는 방식이군요.”
Problems with Static AWS Credentials
전통적으로 CI/CD 파이프라인은 AWS_ACCESS_KEY_ID와 AWS_SECRET_ACCESS_KEY와 같은 자격 증명을 GitHub Secrets에 저장하여 AWS에 접근합니다. 이것은 동작하지만 여러 문제를 야기합니다:
- GitHub에 오래 지속되는 자격 증명이 남아 있음
- 안전하게 교체하기 어려움
- “혹시 몰라”라는 이유로 과도하게 권한이 부여된 정책
- 환경 간 명확한 신뢰 경계가 없음
- 조직이 규모가 커질수록 위험이 증가
팀이 성장하고 환경(공유, dev, staging, prod)이 늘어날수록 이 방식은 보안적으로 확장되지 못합니다.
Moving to OIDC and Role Chaining
정적 비밀 대신 우리는 다음과 같이 전환했습니다:
- GitHub Actions OpenID Connect (OIDC) – 자세한 내용은 이전 블로그 글을 참고하세요.
- 신뢰 정책을 가진 IAM 역할
- 단기간에만 유효한 AWS 자격 증명
- 환경 격리를 위한 역할 체이닝
이 변화가 가져오는 이점:
- GitHub에 AWS 비밀이 저장되지 않음
- 작업이 실행될 때만 자격 증명이 발급됨
- 접근 권한이 엄격히 제한되고 시간 제한이 있음
What Is AWS Role Chaining?
역할 체이닝은 GitHub Actions가 먼저 기본 역할(보통 공유 AWS 계정에 존재)을 가정하고, 그 다음 특정 환경(dev, prod 등)을 위한 대상 역할을 가정한다는 의미입니다.
공항 보안에 비유하면:
- GitHub이 메인 게이트(공유 역할)를 통과합니다.
- 그 후 올바른 터미널(dev/prod 역할)로 안내받습니다.
자유롭게 돌아다니는 것이 없으며, 각 단계가 명시적으로 신뢰됩니다.
How It Works
- 대상 AWS 계정에 GitHub Actions OIDC 공급자를 설정합니다.
- GitHub OIDC 주체를 허용하는 신뢰 정책을 가진 기본 역할을 생성합니다.
- 기본 역할을 신뢰하도록 환경별 역할을 생성합니다.
- 워크플로우에서는
role‑chaining: true옵션을 사용한 공식 AWS 액션을 사용하거나(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-sessionWhy Adopt This Pattern?
보안은 “나중에 추가하는” 것이 아니라 처음부터 워크플로에 내재되어야 합니다. GitHub Actions와 AWS 역할 체이닝을 사용하면:
- CI/CD에서 오래 지속되는 키를 제거
- 환경 간 명확한 신뢰 경계 제공
- 감사 가능성을 높이고 프로덕션 배포에 대한 신뢰도 향상
아직도 CI/CD에서 오래 지속되는 AWS 키를 사용하고 있다면, 이것이 가장 깔끔한 업그레이드 중 하나입니다.
함께 빌드하는 동료들이 더 큰 자신감과 낮은 위험으로 배포할 수 있길 바랍니다. 궁금한 점이 있으면 언제든 댓글 남겨 주세요.