GitHub Actions OIDC 무비밀 배포 실전 가이드: 키 없는 CI/CD를 1주 안에 정착시키는 방법

1) 문제 정의

AWS/GCP/Azure 배포를 GitHub Actions로 자동화할 때 가장 흔한 보안 부채는 장기 비밀키(Access Key/Service Account Key)를 CI 비밀 저장소에 넣어두는 방식입니다. 키가 유출되면 회수 전까지 무제한 악용될 수 있고, 회전 주기를 지키지 못하면 감사 대응도 어렵습니다.

이 글은 DevOps 엔지니어, 백엔드 리드, 보안 담당자가 GitHub OIDC 기반 무비밀(secretsless) 배포를 도입할 때 바로 적용할 수 있도록 작성했습니다. 범위는 GitHub Actions와 클라우드 IAM 연동, 배포 워크플로우 하드닝입니다. 애플리케이션 런타임 보안(코드 취약점 스캔/WAAP)은 제외합니다.

2) 근거 및 비교

접근 방식	초기 구축 시간	운영 비용	유출 시 피해 반경	감사 대응	권장도
A. 장기 키를 GitHub Secrets에 저장	매우 짧음(0.5일)	낮음	큼 (만료 전까지 지속)	취약 (회전/추적 수동)	비추천
B. OIDC + 단기 토큰(STS/Workload Identity)	중간(1~2일)	낮음	작음 (짧은 TTL, 조건부 발급)	강함 (정책/로그 추적 용이)	강력 추천
C. 자체 Vault 브로커 + 동적 자격증명	김(3일+)	중간~높음	작음	강함	대규모 조직 한정

GitHub 공식 문서는 OIDC를 통해 클라우드 제공자에게 워크플로우 ID 토큰을 전달하고, 해당 토큰 클레임(브랜치, 리포지토리, 환경)을 조건으로 단기 권한을 발급하는 패턴을 권장합니다. AWS/Azure/GCP 모두 같은 원리로 운영 가능하며, 장기 키 제거 자체가 감사 리스크를 크게 줄입니다.

3) 단계별 실행 방법

Step 1. 신뢰 경계 정의(브랜치/환경/리포지토리)
예: main 브랜치 + production 환경에서만 배포 권한을 허용합니다. PR/포크에서는 읽기 전용 권한만 유지합니다.

Step 2. 클라우드 IAM에 OIDC 공급자/연합 자격 구성
AWS라면 GitHub OIDC provider를 등록하고, 역할 신뢰 정책에서 sub/aud 조건을 정확히 제한합니다. 예: repo:org/repo:ref:refs/heads/main.

Step 3. 워크플로우에서 id-token 권한 활성화
GitHub Actions YAML에 아래를 추가합니다.

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gha-prod-deploy
          aws-region: ap-northeast-2
      - run: ./scripts/deploy.sh

Step 4. 환경 보호 규칙(Approvals/Wait Timer) 적용
GitHub Environment 보호를 켜고, 프로덕션은 최소 1인 승인 후 실행하도록 강제합니다.

Step 5. 관측성/감사 로그 연결
클라우드 감사 로그(예: CloudTrail)에서 역할 수임 이벤트를 수집해, “어떤 워크플로우가 언제 어떤 권한을 사용했는지”를 대시보드화합니다.

4) 실수/함정 (Pitfalls)

• 함정 1: sub 조건을 와일드카드로 넓게 허용 — 예방: 브랜치/환경 단위로 세분화. 복구: 역할 분리 후 조건 즉시 축소.
• 함정 2: 워크플로우 permissions를 기본값으로 방치 — 예방: job 단위 최소권한 선언. 복구: 실패 로그 기준으로 필요한 권한만 재부여.
• 함정 3: OIDC 전환 후 기존 장기 키를 삭제하지 않음 — 예방: 전환 완료 체크리스트에 키 폐기 포함. 복구: 즉시 비활성화 + 최근 사용 로그 역추적.

5) 실행 체크리스트

• 프로덕션 배포 워크플로우에 id-token: write를 명시했는가?
• IAM 신뢰 정책에서 sub/aud를 리포/브랜치/환경 기준으로 제한했는가?
• 기존 장기 키(Access Key/JSON key)를 모두 폐기했는가?
• GitHub Environment 승인 규칙(최소 1인)을 적용했는가?
• 배포 역할에 최소 권한(배포에 필요한 API만) 원칙을 적용했는가?
• 감사 로그에서 역할 수임 이벤트를 월 1회 점검하는가?

Definition of Done: 프로덕션 배포 경로에서 장기 비밀키 0개, 30일 내 무단 권한 사용 이벤트 0건, 배포 실패율(권한 이슈) 3% 이하.

6) 참고자료

• GitHub Docs - About security hardening with OpenID Connect (확인: 2026-02-28)
• GitHub Docs - Configuring OpenID Connect in Amazon Web Services (확인: 2026-02-28)
• AWS IAM User Guide - Create OpenID Connect (OIDC) identity providers (확인: 2026-02-28)
• GitHub Docs - Automatic token authentication (확인: 2026-02-28)
• Microsoft Learn - Use OpenID Connect with GitHub Actions to access Azure resources (확인: 2026-02-28)

7) 작성자 관점

제가 권하는 기본값은 B안(OIDC + 단기 토큰)입니다. 팀 규모와 무관하게 보안/운영 균형이 가장 좋고, 도입 난이도도 과장된 것보다 낮습니다.

비추천은 “당장 급해서 장기 키를 그대로 둔다”는 타협입니다. 단기적으로는 편하지만, 사고·감사·인수인계 비용을 계속 키웁니다. 단, 다중 클라우드·복잡한 권한 중개가 필요한 대기업이라면 C안(Vault 브로커)을 단계적으로 검토할 가치가 있습니다.