GitHub Actions에 OIDC audience 제약이 필요한 이유

GitHub Actions의 id-token: write는 작업이 임의의 audience로 OIDC 토큰을 발급할 수 있게 해, 취약하거나 악성인 서드파티 코드가 다른 서비스로 권한을 확장할 수 있음 OIDC의 aud 클레임은 토큰을 받아들일 서비스를 제한해, 특정 서비스용 토큰이 탈취돼도 다른 서비스에서 오용되지 않도록 방어함 GitLab CI/CD는 audience를 작업 정의에 정적으로 선언하지만, GitHub Actions는 HTTP 요청의 audience 매개변수로 지정하므로 런타임에 대상을 선택할 수 있음 GitHub는 id-token: [pypi]처럼 허용할 audience를 미리 선언하게 해, PyPI 배포 작업이 sts.amazonaws.com용 토큰을 발급받아 AWS 접근에 악용되는 상황을 막아야 함 동적 audience가 필요한 경우 기존 id-token: write를 덜 안전한 포괄 옵션으로 유지하되, 정적 제약을 지원하면 독립적인 OIDC 연동 서비스 사이의 공격 전환을 줄일 수 있음 CI/CD에서 OIDC가 하는 역할 GitHub Actions는 OpenID Connect(OIDC)를 통해 검증 가능한 워크로드 신원을 제공함 워크플로는 GitHub가 모든 상호작용을 중개하거나 사전 승인하지 않아도 OIDC 토큰으로 외부 서비스와 신뢰 관계를 맺을 수 있음 Trusted Publishing과 Sigstore가 이 구조를 사용함 GitHub Actions 워크플로가 외부 서비스에 OIDC 토큰으로 머신 신원을 제시함 외부 서비스는 이를 인증한 뒤 각각 PyPI 업로드와 아티팩트 서명에 활용함 GitLab과 GitHub의 audience 지정 방식 GitLab CI/CD는 id_tokens 아래에 aud: pypi를 넣어 OIDC audience를 사전에 선언함 my-job: id_tokens: PYPI_ID_TOKEN: aud: pypi script: | do-something.sh --id-token "${PYPI_ID_TOKEN}" GitHub Actions는 먼저 id-token: write 권한을 부여한 뒤, 실행 중 토큰 요청 URL의 audience 매개변수로 대상을 선택함 my-job: runs-on: ubuntu-latest permissions: id-token: write steps: run: | resp=$(curl -H "Authorization: bearer $ACT...