【無料ユーザーも使えます！】GitLab 18.3で正式リリースされた「CI/CD job tokenの権限を絞れる」機能を解説
はじめに
GitLabには無料(Free)プランでも使える機能がたくさんありますが、意外と知られていないものも多いです。今回紹介する「CI/CD job tokenのきめ細かい権限設定(Fine-grained permissions for CI/CD job tokens)」もその一つです。
この機能はGitLab 17.10で実験的機能として導入され、GitLab 18.0でベータに移行し、GitLab 18.3で正式に一般提供(GA)されました。TierはFree, Premium, Ultimate全てで利用可能、提供形態もGitLab.com / Self-Managed / Dedicatedすべてに対応しています。つまり、無料ユーザーの方でもそのまま使えるということです。
この記事では「そもそもjob tokenとは何か」「何が課題だったのか」「18.3で何が変わったのか」を、なるべく噛み砕いて説明します。
CI/CD job tokenとは
GitLabのCI/CDパイプラインでは、ジョブが実行されるたびに自動的に短命な認証情報(job token)が発行されます。このトークンを使うことで、パイプラインの中からGitLabのAPIを呼び出したり、他のプロジェクトのリソースにアクセスしたりできます。
これまでの課題はシンプルで、job tokenは基本的に「そのジョブを実行したユーザーの権限をそのまま引き継ぐ」仕組みになっていたことです。つまり、ちょっとしたCI処理のためだけに、必要以上に広い権限を持つトークンが使われてしまうケースが多々ありました。セキュリティの観点では、これは「最小権限の原則」に反する状態です。
18.3で何が変わったのか
なお、この設定を行うには次の前提条件があります。
- 対象プロジェクトで Maintainer または Owner ロールを持っていること
- プロジェクトで fine-grained permissions 機能自体が有効化されていること
GitLab 18.3では、job tokenがアクセスできるAPIエンドポイントを、プロジェクトごとに細かく制御できるようになりました。具体的には、許可リスト(allowlist)に登録したグループやプロジェクトに対して、「どのAPIエンドポイントを」「読み取りのみか、読み書き両方か」を個別に指定できます。
設定の流れは次の通りです。
- 対象プロジェクトで Settings > CI/CD を開く
- Job token permissions を展開する
- CI/CD job token allowlist から Add を選択
- Group or project を選び、許可したいグループ/プロジェクトのパスを入力
- Fine-grained permissions を選択し、必要なAPIエンドポイントへの権限を付与する
これにより、「このプロジェクトのjob tokenは、あのプロジェクトのパイプライン情報を読むことだけ許可する」といった、ピンポイントな権限設計が可能になります。
ここで少し紛らわしいのが「誰が誰にアクセスするか」の関係です。たとえばプロジェクトAの許可リストにプロジェクトBを追加し、権限を設定したとします。この場合、許可されるのは「プロジェクトBのjob token(=プロジェクトBのパイプラインで発行されたトークン)が、プロジェクトAの指定したリソースにアクセスすること」です。つまり、設定する場所(プロジェクトA)が「アクセスされる側」、許可リストに追加する対象(プロジェクトB)が「アクセスする側」という関係になります。
どんなAPIエンドポイントが対象なのか
対応エンドポイントはかなり広く、たとえば次のようなカテゴリがあります。
- Badges(プロジェクトバッジの取得・追加・更新・削除)
- Deployments(デプロイ情報の取得・作成・更新・削除)
- Environments(環境の取得・作成・停止・削除)
- Jobs(ジョブ一覧・アーティファクトのダウンロードなど)
- Merge requests(マージリクエストやノートの取得)
- Packages(npm、Maven、PyPI、Conan、Composer、Goモジュールなど各種パッケージレジストリの操作)
- Pipelines(パイプライン一覧・取得・メタデータ更新)
- Releases(リリースの取得・作成・更新・削除)
- Repositories(ブランチ・タグ・コミットの取得)
- Secure files(セキュアファイルの取得・作成・削除)
- Terraform state(状態ファイルの取得・更新・ロック)
- Work items(イシューの取得)
各エンドポイントには READ_* (Read=読み取り専用) または ADMIN_* (Read and write=読み書き両方) という権限名が割り当てられており、これを単位として許可・不許可を選べます。
一方で、コンテナレジストリの削除系操作や、DASTのバリデーション遷移、トークン交換のエンドポイントなど、job tokenからは原則アクセスできないエンドポイントも明確に定義されています。「何でもできてしまう」状態を避けつつ、必要な範囲だけを開放できる設計になっているのがポイントです。
なぜ無料ユーザーにもおすすめなのか
セキュリティ強化の機能は、ともすれば「上位プラン限定」というイメージを持たれがちですが、この機能はFree, Premium, Ultimateの全Tierで利用可能です。個人開発や小規模チームのプロジェクトでも、外部プロジェクトとの連携でjob tokenを使っている場合は、ぜひ一度許可リストの設定を見直してみてください。
「とりあえず全部許可」になっている設定を、必要な範囲だけに絞るだけで、意図しないアクセスや事故を未然に防ぐことができます。GitLabは無料プランでもこうした実用的な機能がどんどん追加されているので、使いこなせばできることの幅がぐっと広がります。
まとめ
- GitLab 18.3で「CI/CD job tokenのきめ細かい権限設定」が正式リリース
- Free, Premium, Ultimateの全Tierで利用可能
- プロジェクトの許可リストごとに、アクセスできるAPIエンドポイントを細かく制御できる
- 最小権限の原則をCI/CDパイプラインにも適用しやすくなった
ぜひ自分のプロジェクトでも設定を見直して、GitLabをもっと使いこなしてみてください。