24장 GitLab CI에서 같은 계약을 ID token으로 옮긴다

GitLab은 job의 id_tokens에서 audience를 지정하고 AssumeRoleWithWebIdentity로 temporary credential을 받는다. CI_JOB_JWT_V2는 GitLab 17.0에서 제거되었으므로 오래된 예제를 따라가지 않는다.

GitLab.com에서는 AWS trust condition에 stable namespace_id, project_id를 지원하는지 공식 문서에서 확인하고 path 기반 sub와 함께 사용한다. group·project rename에도 identity가 뜻밖에 바뀌지 않게 하기 위해서다. Self-Managed는 공개 가능한 OIDC discovery endpoint와 올바른 certificate chain이 필요하다.

examples/pipelines/gitlab-ci.yml의 build job은 다음 evidence를 남긴다.

CI_PROJECT_ID + CI_PIPELINE_ID
CI_COMMIT_SHA
assumed role ARN
ECR image URI + digest
scan result

deploy job에는 protected environment와 manual approval을 둔다. GitLab Runner 자체가 privileged Docker-in-Docker를 쓰면 runner isolation과 network·cache·concurrent job 위험을 별도로 review한다. 조직에서는 rootless BuildKit, managed build service 또는 격리된 ephemeral runner를 비교한다.

GitHub에서 GitLab으로 옮길 때 YAML을 번역하는 데 집중하지 않는다. 다음 invariant를 보존한다.

• untrusted merge request는 production role을 못 맡는다.
• build와 deploy role이 분리된다.
• image는 SHA 또는 digest로 불변 식별된다.
• production에는 사람 승인과 protected branch/tag가 있다.
• rollout·smoke·rollback 증거가 남는다.