OpenID Connect (OIDC)를 사용한 ID 토큰 인증

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

서드 파티 서비스를 GitLab CI/CD의 ID 토큰을 사용하여 인증할 수 있습니다.

ID 토큰

ID 토큰은 GitLab CI/CD 작업에 추가할 수 있는 JSON Web Tokens (JWTs)입니다. 이들은 서드 파티 서비스와 OIDC 인증에 사용되며, HashiCorp Vault와 인증하기 위해 secrets 키워드에 의해 사용됩니다.

ID 토큰은 .gitlab-ci.yml에서 구성됩니다. 예를 들어:

job_with_id_tokens:
  id_tokens:
    FIRST_ID_TOKEN:
      aud: https://first.service.com
    SECOND_ID_TOKEN:
      aud: https://second.service.com
  script:
    - first-service-authentication-script.sh $FIRST_ID_TOKEN
    - second-service-authentication-script.sh $SECOND_ID_TOKEN

이 예에서 두 토큰은 다른 aud 클레임을 갖습니다. 서드 파티 서비스는 바운드 오디언스에 매칭되지 않는 토큰을 거부하도록 구성될 수 있습니다. 이 기능을 사용하여 토큰으로 인증할 수 있는 서비스의 수를 줄일 수 있습니다. 이는 토큰의 노출이 심각도를 줄이는 데 도움이 됩니다.

토큰 페이로드

각 ID 토큰에는 다음과 같은 표준 클레임들이 포함됩니다:

필드 설명
iss 토큰의 발행자, 기본적으로 GitLab 인스턴스의 도메인입니다.
sub project_path:{group}/{project}:ref_type:{type}:ref:{branch_name} (“subject” 클레임)
aud 토큰의 의도된 오디언스, 기본적으로는 GitLab 인스턴스의 도메인입니다.
exp 만료 시간
nbf 유효한 토큰이 되기 전의 시간
iat JWT가 발급된 시간
jti 토큰의 고유 식별자 (“JWT ID” 클레임)

토큰은 또한 GitLab에서 제공하는 사용자 정의 클레임을 포함합니다:

필드 일 때 설명
namespace_id 항상 사용자 ID에 의해 그룹 또는 사용자 레벨 네임스페이스를 범위로 지정합니다.
namespace_path 항상 사용자의 경로에 따라 그룹 또는 사용자 레벨 네임스페이스를 범위로 지정합니다.
project_id 항상 프로젝트 ID에 따라 프로젝트를 범위로 지정합니다.
project_path 항상 프로젝트 경로에 따라 프로젝트를 범위로 지정합니다.
user_id 항상 작업을 실행하는 사용자의 ID입니다.
user_login 항상 작업을 실행하는 사용자의 사용자 이름입니다.
user_email 항상 작업을 실행하는 사용자의 이메일입니다.
user_access_level 항상 사용자가 실행하는 작업의 액세스 수준입니다. GitLab 16.9에서 도입되었습니다.
user_identities 사용자 환경 설정 사용자의 외부 식별 정보 디렉터리(GitLab 16.0에서 도입됨).
pipeline_id 항상 파이프라인의 ID입니다.
pipeline_source 항상 파이프라인 원본
job_id 항상 작업의 ID입니다.
ref 항상 작업을 위한 Git ref입니다.
ref_type 항상 Git ref 유형, 즉 branch 또는 tag입니다.
ref_path 항상 작업을 위한 완전히 정규화된 ref입니다. 예: refs/heads/main . GitLab 16.0에서 도입됨.
ref_protected 항상 Git ref가 보호되어 있는 경우 true, 그렇지 않으면 false입니다.
groups_direct 사용자가 0~200개의 그룹의 직접 멤버인 경우 사용자의 직접 멤버십 그룹의 경로입니다. 사용자가 200개 이상의 그룹의 직접 멤버인 경우 생략됩니다. (GitLab 16.11에서 도입됨).
environment 작업이 환경을 지정하는 경우 작업이 배포되는 환경입니다.
environment_protected 작업이 환경을 지정하는 경우 배포된 환경이 보호되어 있는 경우 true, 그렇지 않으면 false입니다.
deployment_tier 작업이 환경을 지정하는 경우 작업이 지정하는 환경의 배포 등급 GitLab 15.2에서 도입됨.
environment_action 작업이 환경을 지정하는 경우 작업에서 지정된 환경 액션(environment:action) (GitLab 16.5에서 도입됨).
runner_id 항상 작업을 실행하는 러너의 ID입니다. GitLab 16.0에서 도입됨.
runner_environment 항상 작업에 의해 사용되는 러너의 종류입니다. gitlab-hosted 또는 self-hosted가 될 수 있습니다. GitLab 16.0에서 도입됨.
sha 항상 작업의 커밋 SHA입니다. GitLab 16.0에서 도입됨.
ci_config_ref_uri 항상 최상위 파이프라인 정의의 ref 경로, 예: gitlab.example.com/my-group/my-project//.gitlab-ci.yml@refs/heads/main. GitLab 16.2에서 도입됨. 이 클레임은 파이프라인 정의가 동일한 프로젝트에 있는 경우에만 null입니다.
ci_config_sha 항상 ci_config_ref_uri의 Git 커밋 SHA입니다. GitLab 16.2에서 도입됨. 이 클레임은 파이프라인 정의가 동일한 프로젝트에 있는 경우에만 null입니다.
project_visibility 항상 파이프라인이 실행되는 프로젝트의 가시성 internal, private, 또는 public이 될 수 있습니다. GitLab 16.3에서 도입됨.

ID 토큰은 RS256을 사용하여 인코딩되며, 전용 개인 키로 서명됩니다. 토큰의 만료 시간은 작업의 타임아웃이 지정된 경우 해당 타임아웃으로 설정되거나 타임아웃이 지정되지 않은 경우 5분으로 설정됩니다.

매뉴얼 ID 토큰 인증

서드 파티 서비스와 OIDC 인증에 ID 토큰을 사용할 수 있습니다. 예를 들면:

manual_authentication:
  variables:
    VAULT_ADDR: http://vault.example.com:8200
  image: vault:latest
  id_tokens:
    VAULT_ID_TOKEN:
      aud: http://vault.example.com
  script:
    - export VAULT_TOKEN="$(vault write -field=token auth/jwt/login role=myproject-example jwt=$VAULT_ID_TOKEN)"
    - export PASSWORD="$(vault kv get -field=password secret/myproject/example/db)"
    - my-authentication-script.sh $VAULT_TOKEN $PASSWORD

HashiCorp Vault를 사용한 자동 ID 토큰 인증

Tier: Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

secrets 키워드를 사용하여 HashiCorp Vault에서 비밀을 자동으로 가져오려면 ID 토큰을 사용할 수 있습니다.

이전에 CI_JOB_JWT를 사용하여 Vault에서 비밀을 가져왔다면, Update HashiCorp Vault configuration to use ID Tokens 튜토리얼을 통해 ID 토큰으로 전환하는 방법을 알아보세요.

자동 ID 토큰 인증 구성

하나의 ID 토큰이 정의된 경우 secrets 키워드는 자동으로 해당 토큰을 사용하여 Vault와 인증합니다. 예를 들면:

job_with_secrets:
  id_tokens:
    VAULT_ID_TOKEN:
      aud: https://vault.example.com
  secrets:
    PROD_DB_PASSWORD:
      vault: example/db/password # $VAULT_ID_TOKEN을 사용하여 인증
  script:
    - access-prod-db.sh --token $PROD_DB_PASSWORD

둘 이상의 ID 토큰이 정의된 경우, token 키워드를 사용하여 어떤 토큰을 사용해야 하는지 지정합니다. 예를 들면:

job_with_secrets:
  id_tokens:
    FIRST_ID_TOKEN:
      aud: https://first.service.com
    SECOND_ID_TOKEN:
      aud: https://second.service.com
  secrets:
    FIRST_DB_PASSWORD:
      vault: first/db/password
      token: $FIRST_ID_TOKEN
    SECOND_DB_PASSWORD:
      vault: second/db/password
      token: $SECOND_ID_TOKEN
  script:
    - access-first-db.sh --token $FIRST_DB_PASSWORD
    - access-second-db.sh --token $SECOND_DB_PASSWORD

문제 해결

400: missing token 상태 코드

이 오류는 ID 토큰에 필요한 하나 이상의 기본 컴포넌트가 누락되거나 기대한 대로 구성되지 않았음을 나타냅니다.

문제를 찾으려면 관리자가 인스턴스의 exceptions_json.log에서 실패한 특정 메서드에 대한 자세한 내용을 찾을 수 있습니다.

GitLab::Ci::Jwt::NoSigningKeyError

exceptions_json.log 파일의 이 오류는 서명 키가 데이터베이스에서 누락되어 토큰을 생성할 수 없기 때문입니다. 이 문제를 확인하려면 인스턴스의 PostgreSQL 터미널에서 다음 쿼리를 실행하여 반환된 값이 비어 있는지 확인하십시오:

SELECT encrypted_ci_jwt_signing_key FROM application_settings;

반환된 값이 비어 있다면 아래의 Rails 스니펫을 사용하여 새 키를 생성하고 내부적으로 교체하십시오:

  key = OpenSSL::PKey::RSA.new(2048).to_pem
  
  ApplicationSetting.find_each do |application_setting|
    application_setting.update(ci_jwt_signing_key: key)
  end