CI/CD job 토큰

CI/CD job 토큰 (CI/CD job token)

CI/CD 파이프라인 job이 실행되기 직전에 GitLab은 고유한 토큰을 생성해서 CI_JOB_TOKEN 사전 정의 변수로 job에 제공해요. 이 토큰은 job이 실행되는 동안에만 유효합니다. job이 끝나면 토큰 접근이 취소되고 더 이상 사용할 수 없어요. 실행 중인 job에서 특정 GitLab 기능에 인증할 때 이 토큰을 씁니다.

출처: 문서

본문

CI/CD job 토큰은 파이프라인을 트리거한 사용자와 같은 접근 수준을 받지만, 개인 액세스 토큰보다 접근 가능한 리소스가 적어요. 사용자는 커밋을 푸시하거나 수동 job을 실행하거나 예약 파이프라인을 소유하는 방식으로 job을 트리거할 수 있어요. 이 사용자는 리소스에 접근하는 데 필요한 권한이 있는 역할이어야 합니다.

job 토큰으로 다른 그룹이나 프로젝트(대상 프로젝트)의 리소스에 접근하도록 GitLab에 인증할 수 있어요. 기본적으로 job 토큰의 그룹 또는 프로젝트는 대상 프로젝트의 허용 목록(allowlist)에 추가되어야 합니다. 프로젝트가 public 또는 internal이면 허용 목록 없이도 일부 기능에 접근할 수 있어요. 예를 들어 프로젝트의 공개 파이프라인에서 artifacts를 가져올 수 있습니다. 이 접근은 제한할 수도 있어요.

job 토큰 접근 (Job token access)

단일 태그 조회 권한은 GitLab 18.8에서 도입.
Badges API 접근 권한은 GitLab 19.1에서 도입.
커밋이 푸시된 모든 참조 나열 권한은 GitLab 19.4에서 도입.

CI/CD job 토큰은 다음 리소스에 접근할 수 있어요.

리소스	참고
Badges API	이 API의 모든 엔드포인트에 접근 가능.
Branches API	`GET /projects/:id/repository/branches` 엔드포인트에 접근 가능.
Commits API	`GET /projects/:id/repository/commits/:sha`, `GET /projects/:id/repository/commits/:sha/merge_requests`, `GET /projects/:id/repository/commits/:sha/refs` 엔드포인트에 접근 가능.
Container registry	job의 프로젝트와 연결된 컨테이너 레지스트리 인증에 사전 정의 변수 `$CI_REGISTRY_PASSWORD`로 사용.
Package registry	레지스트리 인증에 사용.
Terraform module registry	레지스트리 인증에 사용.
Secure files	job에서 secure files를 쓰는 `glab securefile` 명령이 사용.
Container registry API	job의 프로젝트와 연결된 컨테이너 레지스트리로만 인증 가능.
Deployments API	이 API의 모든 엔드포인트에 접근 가능.
Environments API	이 API의 모든 엔드포인트에 접근 가능.
Files API	`GET /projects/:id/repository/files/:file_path/raw` 엔드포인트에 접근 가능.
Jobs API	`GET /job` 엔드포인트에만 접근 가능.
Job artifacts API	다운로드 엔드포인트에만 접근 가능.
Merge requests API	`GET /projects/:id/merge_requests`와 `GET /projects/:id/merge_requests/:merge_request_iid` 엔드포인트에 접근 가능.
Notes API	`GET /projects/:id/merge_requests/:merge_request_iid/notes`와 `GET /projects/:id/merge_requests/:merge_request_iid/notes/:note_id` 엔드포인트에 접근 가능.
Packages API	이 API의 모든 엔드포인트에 접근 가능.
Pipeline trigger tokens API	`POST /projects/:id/trigger/pipeline` 엔드포인트에만 접근 가능.
Pipelines API	`PUT /projects/:id/pipelines/:pipeline_id/metadata` 엔드포인트에만 접근 가능.
Release links API	이 API의 모든 엔드포인트에 접근 가능.
Releases API	이 API의 모든 엔드포인트에 접근 가능.
Repositories API	`GET /projects/:id/repository/archive`와 `GET /projects/:id/repository/changelog` 엔드포인트에 접근 가능.
Tags API	`GET /projects/:id/repository/tags`와 `GET /projects/:id/repository/tags/:tag_name` 엔드포인트에 접근 가능.

권한을 더 세분화하려는 공개 제안이 있습니다.

GitLab CI/CD job 토큰 보안 (GitLab CI/CD job token security)

job 토큰이 유출되면 CI/CD job을 실행한 사용자에게 접근 가능한 프라이빗 데이터에 접근할 수 있어요. 이 토큰의 유출·오용을 막기 위해 GitLab은:

job 로그에서 job 토큰을 마스킹합니다.
job이 실행 중일 때만 job 토큰에 권한을 부여합니다.

또한 러너도 안전하게 구성해야 해요.

머신을 재사용한다면 Docker privileged 모드 사용을 피하세요.
job이 같은 머신에서 실행된다면 shell executor 사용을 피하세요.

안전하지 않은 GitLab Runner 구성은 다른 job의 토큰을 훔칠 위험을 높여요.

프로젝트에 대한 job 토큰 접근 제어 (Control job token access to your project)

어떤 그룹이나 프로젝트가 job 토큰으로 인증해서 프로젝트의 일부 리소스에 접근할 수 있는지 제어할 수 있어요. 기본적으로 job 토큰 접근은 프로젝트의 파이프라인에서 실행되는 CI/CD job으로만 제한됩니다. 다른 프로젝트의 파이프라인에서 job 토큰으로 인증하도록 그룹이나 프로젝트를 허용하려면:

그룹 또는 프로젝트를 job 토큰 허용 목록에 추가해야 해요.
job을 트리거하는 사용자가 여러분의 프로젝트 멤버여야 해요.
사용자가 작업을 수행할 권한이 있어야 합니다.

프로젝트가 public 또는 internal이면 일부 공개 리소스를 어떤 프로젝트의 job 토큰으로도 접근할 수 있어요. 이 리소스는 허용 목록의 프로젝트로만 제한할 수도 있습니다. GitLab Self-Managed 관리자는 이 설정을 오버라이드·강제할 수 있어요. 설정이 강제되면 CI/CD job 토큰은 항상 프로젝트의 허용 목록으로 제한됩니다.

그룹 또는 프로젝트를 job 토큰 허용 목록에 추가 (Add a group or project to the job token allowlist)

허용 목록에 그룹 추가는 GitLab 17.0에서 도입.
GitLab 17.2에서 Token Access 섹션의 이름이 Job token permissions으로, Limit access to this project 설정이 Authorized groups and projects로 변경.
GitLab 17.3에서 Authorized groups and projects 설정이 CI/CD job token allowlist로 변경.
GitLab 17.6에서 Add project 옵션의 이름이 Add로 변경.

인증에 job 토큰을 쓰는 프로젝트의 리소스에 대한 접근을 허용하려면 그룹이나 프로젝트를 job 토큰 허용 목록에 추가할 수 있어요. 기본적으로 어떤 프로젝트의 허용 목록도 자기 자신만 포함합니다. 교차 프로젝트 접근이 필요할 때만 그룹이나 프로젝트를 허용 목록에 추가하세요. 허용 목록에 프로젝트를 추가한다고 허용 목록 프로젝트의 멤버에게 추가 권한이 주어지지는 않아요. 그들은 허용 목록 프로젝트의 job 토큰으로 여러분의 프로젝트에 접근하려면 이미 여러분의 프로젝트 리소스에 접근할 권한이 있어야 합니다.

예를 들어 프로젝트 A는 프로젝트 B를 A의 허용 목록에 추가할 수 있어요. 프로젝트 B(“허용된 프로젝트”)의 CI/CD job은 이제 CI/CD job 토큰으로 API 호출에 인증해서 프로젝트 A에 접근할 수 있습니다. 그룹을 허용 목록에 추가하면 그 항목이 해당 그룹의 모든 프로젝트와 어떤 깊이의 서브그룹에도 접근을 줍니다. GitLab은 job이 토큰을 쓸 때마다 일치를 평가하므로, 나중에 그룹에 추가된 프로젝트도 허용 목록을 바꾸지 않고 포함됩니다. 예를 들어 프로젝트 A는 example-group 그룹을 허용 목록에 추가합니다. 그러면 example-group/team-b/project-c의 job들이 job 토큰으로 프로젝트 A에 접근할 수 있고, 이후 example-group 아래에 만들어진 어떤 프로젝트의 job들도 마찬가지예요.

사전 요구사항:

현재 프로젝트에 대해 Maintainer 또는 Owner 역할이 있어야 해요. 허용된 프로젝트가 internal 또는 private라면 그 프로젝트에서 Guest, Planner, Reporter, Developer, Maintainer, Owner 역할이 있어야 합니다.
허용 목록에 그룹 200개를 넘을 수 없고, 프로젝트 200개를 넘을 수 없습니다. 두 제한은 별도로 계산돼요.

허용 목록에 그룹 또는 프로젝트를 추가하려면:

상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
Job token permissions을 펼칩니다.
CI/CD job token allowlist 오른쪽에서 Add를 선택합니다.
Group or project를 선택합니다.
허용 목록에 추가할 그룹 또는 프로젝트의 경로를 입력하고 Add를 선택합니다.

API로도 그룹이나 프로젝트를 허용 목록에 추가할 수 있어요.

public 또는 internal 프로젝트의 job 토큰 범위 제한 (Limit job token scope for public or internal projects)

저장소 접근은 GitLab 17.0에서 도입.

허용 목록에 없는 프로젝트는 job 토큰으로 public 또는 internal 프로젝트에 인증해서 다음을 할 수 있어요.

Artifacts 가져오기.
컨테이너 레지스트리 접근.
패키지 레지스트리 접근.
릴리스, 배포, 환경 접근.
저장소 접근.

각 기능을 프로젝트 멤버에게만 보이도록 설정해서 이 접근을 허용 목록의 프로젝트로만 제한할 수 있어요.

사전 요구사항:

프로젝트에 대해 Maintainer 역할이 있어야 해요.

기능을 프로젝트 멤버에게만 보이도록 설정하려면:

상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 Settings > General을 선택합니다.
Visibility, project features, permissions을 펼칩니다.
접근을 제한하려는 기능의 가시성을 Only project members로 설정합니다.
- artifacts 가져오기 접근은 CI/CD 가시성 설정이 제어합니다.
Save changes를 선택합니다.

어떤 프로젝트든 프로젝트에 접근하도록 허용 (Allow any project to access your project)

Offering: GitLab Self-Managed, GitLab Dedicated

[!WARNING] 토큰 접근 제한과 허용 목록을 비활성화하는 것은 보안 위험입니다. 악성 사용자가 권한이 없는 프로젝트에서 만들어진 파이프라인을 손상시키려 할 수 있어요. 파이프라인이 여러분의 유지 관리자 중 한 명이 만든 것이라면 job 토큰이 여러분의 프로젝트에 접근하려는 시도에 사용될 수 있습니다.

CI/CD job 토큰 허용 목록을 비활성화하면 어떤 프로젝트의 job도 job 토큰으로 여러분의 프로젝트에 접근할 수 있어요. 파이프라인을 트리거하는 사용자는 여러분의 프로젝트에 접근할 권한이 있어야 합니다. 이 설정은 테스트나 비슷한 이유로만 끄고, 가능한 한 빨리 다시 켜야 해요. 이 옵션은 Enable and enforce job token allowlist for all projects 설정이 비활성화된 GitLab Self-Managed 또는 GitLab Dedicated 인스턴스에서만 사용할 수 있어요.

사전 요구사항:

프로젝트에 대해 Maintainer 또는 Owner 역할이 있어야 해요.

job 토큰 허용 목록을 비활성화하려면:

상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
Job token permissions을 펼칩니다.
All groups and projects를 선택합니다.
권장. 테스트가 끝나면 This project and any groups and projects in the allowlist를 선택해서 job 토큰 허용 목록을 다시 활성화합니다.

GraphQL(inboundJobTokenScopeEnabled) 또는 REST API로도 이 설정을 수정할 수 있어요.

프로젝트 저장소에 Git push 요청 허용 (Allow Git push requests to your project repository)

allow_push_repository_for_job_token이라는 기능 플래그와 함께 GitLab 17.2에서 도입. 기본적으로 비활성화.
GitLab 18.3에서 GitLab.com에 활성화.
GitLab 18.4에서 일반 공개. 기능 플래그 allow_push_repository_for_job_token 제거.

CI/CD job 토큰으로 인증된 Git push 요청을 허용하도록 프로젝트를 구성할 수 있어요. 이 설정은 기본적으로 꺼져 있습니다. 이 설정을 켜면 프로젝트 파이프라인에서 실행되는 CI/CD job이 생성한 job 토큰만 프로젝트에 푸시할 수 있어요. job 토큰으로 프로젝트에 푸시할 때는 CI/CD 파이프라인이 트리거되지 않습니다. job 토큰은 job을 시작한 사용자와 같은 접근 권한을 가집니다. semantic-release 도구를 쓴다면 이 설정이 파이프라인 생성을 막을 수 있어요.

[!WARNING] pull mirror로 구성된 프로젝트에서는 이 설정을 켜지 마세요. 특히 미러 업데이트마다 파이프라인이 실행된다면 더더욱요. 업스트림 저장소 소유자가 CI_JOB_TOKEN을 사용해 미러된 프로젝트에 커밋을 푸시하려 할 수 있습니다.

사전 요구사항:

프로젝트에 대해 Maintainer 또는 Owner 역할이 있어야 해요.

프로젝트에서 생성된 job 토큰에 프로젝트 저장소로 푸시할 권한을 부여하려면:

상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
Job token permissions을 펼칩니다.
Permissions 섹션에서 Allow Git push requests to the repository를 선택합니다.

projects API의 ci_push_repository_for_job_token_allowed 매개변수로도 이 설정을 제어할 수 있어요.

허용 목록 프로젝트의 교차 프로젝트 Git push 요청 허용 (Allow cross-project Git push requests from allowlisted projects)

allow_push_to_allowlisted_projects라는 기능 플래그와 함께 GitLab 19.0에서 도입. 기본적으로 비활성화.
GitLab 19.1에서 일반 공개. 기능 플래그 allow_push_to_allowlisted_projects 제거.

허용 목록 프로젝트의 CI/CD job 토큰이 여러분의 프로젝트 저장소로 푸시하도록 허용할 수 있어요. 교차 프로젝트 푸시는 GitOps 워크플로우, 서브모듈 태깅, 교차 저장소 CI/CD 파이프라인에 장기 액세스 토큰을 피하게 해줍니다. job 토큰 푸시가 성공하면 대상 프로젝트에서 CI/CD 파이프라인이 트리거되지 않습니다.

[!WARNING] pull mirror로 구성된 프로젝트에서는 이 설정을 켜지 마세요. 특히 미러 업데이트마다 파이프라인이 트리거된다면 더더욱요. 허용 목록 소스 프로젝트의 소유자가 CI/CD job 토큰을 사용해 여러분의 미러된 프로젝트로 커밋을 푸시할 수 있습니다.

교차 프로젝트 푸시가 동작하려면 다음이 모두 true여야 해요.

대상 프로젝트에 Allow Git push requests to the repository가 활성화.
대상 프로젝트에 Allow cross-project Git push requests from allowlisted projects가 활성화.
대상 프로젝트에 job token allowlist가 활성화.
소스 프로젝트가 대상 프로젝트의 허용 목록에 admin_repositories 세분화 권한으로 추가되어 있거나, 기본 권한(세분화 제한 없음)으로 추가되어 있어야 해요. 소스 프로젝트를 포함하는 허용 목록의 그룹 항목도 이 요구사항을 충족합니다.
파이프라인을 시작한 사용자가 대상 프로젝트에서 최소 Developer 역할이어야 해요.

사전 요구사항:

프로젝트에 대해 Maintainer 또는 Owner 역할이 있어야 해요.

교차 프로젝트 push 요청을 허용하려면:

상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
Settings > CI/CD를 선택합니다.
Job token permissions을 펼칩니다.
Permissions 섹션에서 Allow Git push requests to the repository를 선택합니다.
Allow cross-project Git push requests from allowlisted projects를 선택합니다.
Save Changes를 선택합니다.
소스 프로젝트 또는 그 그룹을 허용 목록에 추가할 때 ADMIN_REPOSITORIES 세분화 권한으로 추가하거나 기본 권한을 활성화해 둡니다. 허용 목록 항목에서 ADMIN_REPOSITORIES는 Repositories의 Read and write 옵션이에요. REST API 엔드포인트에 대한 접근이 아니라 Git push 접근을 부여하므로 세분화 권한 엔드포인트 테이블에는 나타나지 않습니다.

job 토큰의 세분화 권한 (Fine-grained permissions for job tokens)

세분화 권한으로 제한된 REST API 엔드포인트 집합에 명시적으로 접근을 허용할 수 있어요. 자세한 내용은 CI/CD job 토큰의 세분화 권한을 참고하세요.

Git 저장소 클로닝 (Git repository cloning)

job 토큰을 사용해서 CI/CD job에서 프라이빗 프로젝트의 저장소를 인증하고 클론할 수 있어요. 사용자는 gitlab-ci-token, 비밀번호는 job 토큰 값을 씁니다. 예를 들면 이렇습니다.

git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.example.com/<namespace>/<project>

HTTPS 프로토콜이 그룹, 프로젝트 또는 인스턴스 설정으로 비활성화되어도 이 job 토큰으로 저장소를 클론할 수 있어요.

REST API 인증 (REST API authentication)

특정 REST API 엔드포인트에 대한 요청 인증에 job 토큰을 쓸 수 있어요. 방법은 이렇습니다.

헤더: --header "JOB-TOKEN: $CI_JOB_TOKEN" (권장)
폼: --form "token=$CI_JOB_TOKEN"
데이터: --data "job_token=$CI_JOB_TOKEN"
URL의 쿼리 문자열: ?job_token=$CI_JOB_TOKEN (권장하지 않음)

권장하는 헤더 방식의 예시:

curl --verbose --request POST --header "JOB-TOKEN: $CI_JOB_TOKEN" --form ref=master "https://gitlab.com/api/v4/projects/1234/trigger/pipeline"

토큰 보안 지침은 보안 고려 사항을 참고하세요. GraphQL 요청 인증에는 job 토큰을 쓸 수 없습니다.

job 토큰 인증 로그 (Job token authentication log)

GitLab 17.6에서 도입.

어떤 다른 프로젝트가 CI/CD job 토큰으로 여러분의 프로젝트에 인증하는지 인증 로그에서 추적할 수 있어요. 로그를 확인하려면:

상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
Job token permissions을 펼칩니다. Authentication log 섹션이 job 토큰으로 인증해 여러분의 프로젝트에 접근한 다른 프로젝트 목록을 표시해요.
선택 사항. Download CSV를 선택해서 전체 인증 로그를 CSV 형식으로 다운로드합니다.

인증 로그는 최대 100개의 인증 이벤트를 표시해요. 이벤트 수가 100개를 넘으면 CSV 파일을 다운로드해서 로그를 확인하세요. 프로젝트에 대한 새 인증은 인증 로그에 나타나기까지 최대 5분이 걸릴 수 있습니다.

CI/CD 토큰에 레거시 형식 사용 (Use legacy format for CI/CD tokens)

GitLab 17.10에서 도입.

GitLab 19.0부터 CI/CD job 토큰은 기본적으로 JWT 표준을 사용해요. 프로젝트는 최상위 그룹을 구성해서 레거시 형식을 계속 쓸 수 있습니다. 이 설정은 GitLab 20.0 릴리스까지 사용할 수 있어요. CI/CD 토큰에 레거시 형식을 쓰려면:

상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
General pipelines을 펼칩니다.
Enable JWT format for CI/CD job tokens을 끕니다.

이제 CI/CD 토큰이 레거시 형식을 사용해요. 나중에 JWT 형식을 다시 쓰고 싶다면 이 설정을 다시 켤 수 있습니다.

트러블슈팅 (Troubleshooting)

CI job 토큰 실패는 보통 404 Not Found 같은 응답으로 나타나요.

권한 없는 Git clone:

$ git clone https://gitlab-ci-token:[email protected]/fabiopitino/test2.git

Cloning into 'test2'...
remote: The project you were looking for could not be found or you don't have permission to view it.
fatal: repository 'https://gitlab-ci-token:[MASKED]@gitlab.com/<namespace>/<project>.git/' not found

권한 없는 패키지 다운로드:

$ wget --header="JOB-TOKEN: $CI_JOB_TOKEN" ${CI_API_V4_URL}/projects/1234/packages/generic/my_package/0.0.1/file.txt

--2021-09-23 11:00:13--  https://gitlab.com/api/v4/projects/1234/packages/generic/my_package/0.0.1/file.txt
Resolving gitlab.com (gitlab.com)... 172.65.251.78, 2606:4700:90:0:f22e:fbec:5bed:a9b9
Connecting to gitlab.com (gitlab.com)|172.65.251.78|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2021-09-23 11:00:13 ERROR 404: Not Found.

권한 없는 API 요청:

$ curl --verbose --request POST --form "token=$CI_JOB_TOKEN" --form ref=master "https://gitlab.com/api/v4/projects/1234/trigger/pipeline"

< HTTP/2 404
< date: Thu, 23 Sep 2021 11:00:12 GMT
{"message":"404 Not Found"}
< content-type: application/json

CI/CD job 토큰 인증 문제를 트러블슈팅할 때 알아둘 점:

프로젝트별로 범위 설정을 토글하는 GraphQL 예시 mutation이 제공됩니다.
이 주석은 Bash와 cURL로 GraphQL을 사용하는 방법을 보여줘요:
- 인바운드 토큰 접근 범위를 활성화.
- 프로젝트 B가 A에 접근하도록 허용하거나 B를 A의 허용 목록에 추가.
- 프로젝트 접근 제거.
CI job 토큰은 job이 더 이상 실행되지 않거나, 삭제(erased)되었거나, 프로젝트가 삭제되는 중이면 무효가 됩니다.

`semantic-release` 도구와 job 토큰 (The `semantic-release` tool and job tokens)

Allow Git push requests to the repository 설정과 함께 semantic-release 도구를 쓰면 알려진 이슈가 있어요. 활성화되면:

도구가 개인 액세스 토큰을 쓰도록 구성되어 있어도 job 토큰으로 인증해요.
job 토큰은 새 파이프라인을 트리거하지 않으므로 릴리스 파이프라인이 실행되지 않을 수 있어요.

자세한 내용은 이슈 891을 참고하세요.

JWT 형식 job 토큰 오류 (JWT format job token errors)

CI/CD job 토큰의 JWT 형식에는 다음 알려진 이슈가 있어요.

EC2 Fargate 러너 커스텀 executor에서 `Error when persisting the task ARN.` 오류

EC2 Fargate 커스텀 executor의 0.5.0 및 이전 버전에 버그가 있어요. 이 이슈로 Error when persisting the task ARN. Will stop the task for cleanup 오류가 발생합니다. 이 문제를 고치려면 Fargate 커스텀 executor를 0.5.1 이상 버전으로 업그레이드하세요.

`base64` 인코딩의 `invalid character '\n' in string literal` 오류

base64로 job 토큰을 인코딩하면 invalid character '\n' 오류를 받을 수 있어요. base64 명령의 기본 동작은 79자보다 긴 문자열을 줄바꿈으로 감싸요. job 실행 중에 echo $CI_JOB_TOKEN | base64처럼 JWT 형식 job 토큰을 base64로 인코딩하면 토큰이 무효가 됩니다. 이 문제를 고치려면 base64 -w0를 사용해서 토큰을 자동으로 줄바꿈하지 않도록 하세요.

장기 실행 job의 `403 Forbidden` 오류

GitLab 18.8 및 이전 버전에서 JWT 형식 job 토큰을 사용하면 job이 403 Forbidden 오류로 실패할 수 있어요. 이는 다음에서 발생할 수 있습니다:

needs를 사용하는 job.
자식 파이프라인의 job.
콘솔 출력 없이 약 6분 넘게 실행되는 job.

이 오류는 보통 러너 로그에 이렇게 나타났어요.

WARNING: Submitting job to coordinator... job failed
  code=403 job=<job_id> status=PUT https://gitlab.com/api/v4/jobs/<job_id>: 403 Forbidden

이 문제를 피하려면 GitLab 18.9로 업데이트하세요.

더 알아보기

job 토큰은 실행 중인 job이 GitLab API에 안전하게 인증하는 방법이에요. 권한이 파이프라인 트리거 사용자와 같지만 접근 리소스가 제한적이라는 점을 기억하세요. 교차 프로젝트 접근이 필요하면 대상 프로젝트의 허용 목록에 그룹·프로젝트를 추가하는 방식으로 최소 권한 원칙을 지키는 게 좋아요. 토큰 유출을 막으려면 job 로그 마스킹과 러너 보안, 지속적으로 켜 두지 말아야 할 설정들을 확인하세요.

CI/CD job 토큰

CI/CD job 토큰 (CI/CD job token)

본문

job 토큰 접근 (Job token access)

GitLab CI/CD job 토큰 보안 (GitLab CI/CD job token security)

프로젝트에 대한 job 토큰 접근 제어 (Control job token access to your project)

그룹 또는 프로젝트를 job 토큰 허용 목록에 추가 (Add a group or project to the job token allowlist)

public 또는 internal 프로젝트의 job 토큰 범위 제한 (Limit job token scope for public or internal projects)

어떤 프로젝트든 프로젝트에 접근하도록 허용 (Allow any project to access your project)

프로젝트 저장소에 Git push 요청 허용 (Allow Git push requests to your project repository)

허용 목록 프로젝트의 교차 프로젝트 Git push 요청 허용 (Allow cross-project Git push requests from allowlisted projects)

job 토큰의 세분화 권한 (Fine-grained permissions for job tokens)

Git 저장소 클로닝 (Git repository cloning)

REST API 인증 (REST API authentication)

job 토큰 인증 로그 (Job token authentication log)

CI/CD 토큰에 레거시 형식 사용 (Use legacy format for CI/CD tokens)

트러블슈팅 (Troubleshooting)

semantic-release 도구와 job 토큰 (The semantic-release tool and job tokens)

JWT 형식 job 토큰 오류 (JWT format job token errors)

EC2 Fargate 러너 커스텀 executor에서 Error when persisting the task ARN. 오류

base64 인코딩의 invalid character '\n' in string literal 오류

장기 실행 job의 403 Forbidden 오류

더 알아보기

`semantic-release` 도구와 job 토큰 (The `semantic-release` tool and job tokens)

EC2 Fargate 러너 커스텀 executor에서 `Error when persisting the task ARN.` 오류

`base64` 인코딩의 `invalid character '\n' in string literal` 오류

장기 실행 job의 `403 Forbidden` 오류