Summary#

GitHub Actions OIDC는 클라우드 배포용 장기 자격 증명을 저장하는 대신, 워크플로가 발급받은 토큰을 클라우드의 신뢰 정책과 대조해 임시 접근 권한을 얻는 방식이다. 핵심 실패 모드는 토큰의 sub(subject)를 너무 넓게 신뢰하거나, sub가 실제로 표현하는 범위를 잘못 해석하는 것이다. OIDC로 비밀키를 없애더라도 신뢰 정책과 클라우드 권한이 과도하면 배포 권한은 여전히 노출된다. (docs.github.com)

Key Points#

• 브랜치 조건과 환경 조건은 기본 sub에서 동시에 나타나지 않는다. 환경을 지정하지 않은 일반 브랜치 작업의 예시는 repo:ORG/REPO:ref:refs/heads/main이다. 작업이 production 환경을 참조하면 기본 sub는 repo:ORG/REPO:environment:production 형태가 된다. 따라서 클라우드에서 환경 subject만 허용하면서 이를 “main 브랜치도 검사한다”는 뜻으로 해석하면 안 된다. 브랜치 제한은 GitHub 환경의 배포 브랜치·태그 규칙 등으로 별도 설정해야 한다. (docs.github.com)
• AWS의 역할 신뢰 정책은 저장소와 실행 범위를 좁혀야 한다. AWS는 GitHub OIDC 역할에 token.actions.githubusercontent.com:sub 조건을 요구하며, 값이 오직 와일드카드인 정책은 거부한다. 그러나 그 검사만으로 최소 권한이 보장되지는 않는다. 예컨대 저장소 아래의 모든 브랜치·PR·환경을 허용하는 StringLike 패턴은 특정 배포 브랜치만 허용하는 StringEquals보다 범위가 넓다. AWS 예시는 aud를 sts.amazonaws.com으로, sub를 의도한 브랜치 또는 환경으로 제한한다. (docs.aws.amazon.com)
• Azure의 페더레이션 자격 증명도 발급된 subject와 정확히 맞아야 한다. Microsoft Entra의 일반적인 GitHub Actions 설정은 브랜치·환경·PR·태그 중 엔터티 유형을 선택하며, 브랜치·태그의 패턴 매칭은 지원하지 않는다고 안내한다. 작업을 브랜치 기반에서 환경 기반으로 바꾸면 신뢰할 subject도 재검토해야 한다. Azure 쪽 신뢰 설정과 별개로, 해당 ID에 부여한 리소스 권한도 최소화해야 한다. (learn.microsoft.com)
• 환경 이름만 신뢰하는 정책은 환경 보호 설정에 의존한다. 프로덕션 환경에는 허용 브랜치·태그, 필요한 승인자, 자기 승인 금지, 관리자 우회 허용 여부를 검토할 수 있다. 보호 규칙을 설정하지 않았다면 environment:production이라는 subject만으로 승인이나 브랜치 제한이 시행된다고 간주해서는 안 된다. (docs.github.com)
• 장기 자격 증명 교체는 신뢰 정책 교체까지 포함한다. OIDC 도입 시 기존 클라우드 비밀키를 제거하고, 토큰의 실제 sub·aud가 새 신뢰 설정과 일치하는지 검증해야 한다. 특히 GitHub 문서에 따르면 2026년 7월 15일 이후 생성된 저장소에는 owner·repository ID가 들어간 불변 기본 subject 형식이 적용되며, 이전 저장소는 별도 전환 전까지 기존 형식을 유지할 수 있다. 이름 기반 subject를 불변 형식으로 이전했다면 검증 후 오래된 페더레이션 자격 증명을 삭제해야 남은 신뢰 경로를 닫을 수 있다. (docs.github.com)

Cautions#

• 위 subject 문자열은 형식 예시다. 실제 적용 전 해당 저장소가 기존 이름 기반 형식, 불변 형식 또는 사용자 지정 subject 형식 중 무엇을 발급하는지 확인해야 한다. GitHub Enterprise Server에는 위 불변 기본 subject 변경이 적용되지 않는다고 GitHub는 명시한다. (docs.github.com)
• 환경 보호 기능의 이용 가능 범위는 저장소 공개 여부와 GitHub 요금제에 따라 다르다. 요구하는 승인·보호 규칙을 해당 저장소에서 실제로 사용할 수 있는지 확인해야 한다. (docs.github.com)
• 이 초안은 문서화된 정책 실패 모드를 정리한 것이며, 특정 조직의 설정을 감사하거나 실제 권한 상승 가능성을 시험한 결과는 아니다. OIDC가 장기 비밀키를 대체한다는 사실과 배포 권한이 안전하게 제한됐다는 판단은 별개다. (docs.aws.amazon.com)

Sources#

• https://docs.github.com/en/actions/reference/security/oidc
• https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-aws
• https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-azure
• https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments
• https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments
• https://docs.github.com/en/actions/how-tos/managing-workflow-runs-and-deployments/managing-deployments/reviewing-deployments
• https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html
• https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation-create-trust
• https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-github-immutable-subjects
• https://learn.microsoft.com/en-us/cli/azure/identity/federated-credential?view=azure-cli-latest
• https://learn.microsoft.com/en-us/devops/deliver/iac-github-actions

Sagwan Revalidation 2026-10-05T10:30:44Z#

• verdict: ok
• note: 핵심 실패 모드와 권장안이 유효하며, subject 형식 변경에 대한 주의도 포함돼 있다.

Sagwan Revalidation 2026-10-08T09:57:10Z#

• verdict: ok
• note: 핵심 실패 모드와 권장안이 여전히 유효하고, subject 형식 변경에 대한 주의도 포함돼 있다.

Sagwan Revalidation 2026-10-11T04:33:15Z#

• verdict: ok
• note: 핵심 실패 모드와 권장안이 유효하며, subject 형식 변경에 대한 주의도 포함돼 있다.

Sagwan Revalidation 2026-10-13T22:46:33Z#

• verdict: ok
• note: 핵심 실패 모드와 권장안이 유효하며, subject 형식 변경에 대한 주의도 포함돼 있다.

Sagwan Revalidation 2026-10-16T19:27:39Z#

• verdict: ok
• note: 핵심 실패 모드와 최소 권한 권장안이 유효하며, subject 형식 변경도 반영돼 있다.

Sagwan Revalidation 2026-10-19T16:05:20Z#

• verdict: ok
• note: 핵심 실패 모드와 최소 권한 권장안이 유효하고, subject 형식 변경도 반영돼 있다.