【入門編】GitLab「Job Token」による安全なクロスプロジェクト連携：認可範囲を最小化するアクセスコントロールの設計 – バージョン管理・CI/CD活用バイブル

GitLab CI/CDの深淵へようこそ。

現場でよく見る「とりあえず個人のアクセストークンを環境変数にベタ書きする」という光景。あれは、セキュリティの地雷を埋めているのと同じです。もしそのトークンが漏洩したら？あるいは、その担当者がプロジェクトを離れたら？

今日は、そんな泥臭い運用から卒業し、「GitLab CI/CD Job Token」を使って、システムとして美しく、かつ鉄壁のセキュリティを誇るクロスプロジェクト連携を実現する方法を伝授します。

これをマスターすれば、あなたのパイプラインは「運用者の権限」から解放され、真に「システムが自律的に動く」アーキテクチャへと進化します。

—

1. なぜ「Job Token」なのか？

通常、CI/CDで他のリポジトリの成果物（パッケージやコンテナイメージ）をダウンロードしたり、APIを叩いたりする際、多くの人は「Personal Access Token (PAT)」を使います。

しかし、これは以下の理由で「アンチパターン」です。

権限が強すぎる: PATはその人の全プロジェクトにアクセスできてしまう。
ライフサイクル管理が困難: 個人の退職や異動でトークンが無効化され、突然CIが全滅する。

Job Token (`CI_JOB_TOKEN`) は違います。これは「実行中のジョブそのもの」に付与される一時的な認証情報です。ジョブが終われば消滅し、権限もそのジョブが必要とする最小範囲に絞り込めます。まさに、DevOpsの理想形なのです。

—

2. 基礎セットアップ：まずは「許可」を与える

Job Tokenを使うには、「どのプロジェクトが、どのプロジェクトの資源を使えるか」をGitLabに明示的に教える必要があります。これを怠ると「403 Forbidden」の壁に突き当たります。

設定手順：

1. リソースを提供する側のプロジェクト（例：共通ライブラリ）に移動。
2. `Settings` > `CI/CD` > `Token Access` を開く。
3. `Allow access to this project with a CI_JOB_TOKEN` にチェックを入れる。
4. `Add project` で、利用側（クライアント）のプロジェクトパスを指定する。

これで、「認証の握手」ができる状態になります。

—

3. 実践：Job Tokenで成果物を取得する

では、実際に別のプロジェクトのパッケージをダウンロードするHelloWorld的な動作確認を行いましょう。

`.gitlab-ci.yml` の設計

利用側のプロジェクトにて
fetch_artifact_job:
stage: build
script:
# GitLabのAPI経由で、他のプロジェクトの最新成果物を取得する
# $CI_JOB_TOKEN は環境変数として自動注入される魔法の鍵

curl –header “JOB-TOKEN: $CI_JOB_TOKEN” \
“https://gitlab.example.com/api/v4/projects//packages/generic/my-package/1.0.0/artifact.zip” \
–output artifact.zip
only:

main

ここがポイント:

`JOB-TOKEN` ヘッダーに `$CI_JOB_TOKEN` を渡すだけ。これだけで、GitLabは「このジョブは認証済みである」と判断します。
認証情報のハードコードはゼロ。これがセキュリティの「正解」です。

—

4. 現場で震えるほど重要な「落とし穴」回避策

初心者が必ずハマるポイント、そしてプロが必ず守るルールを伝授します。

① 最小権限の原則 (Principle of Least Privilege)

デフォルトでは、Job Tokenは「プロジェクト内のすべて」にアクセスできる可能性があります。`Token Access` 設定画面で、「許可するプロジェクトを明示的に指定（Allow-list）」する運用を徹底してください。全開放は、セキュリティの穴を広げるだけです。

② CI_JOB_TOKEN の漏洩を防ぐ

`CI_JOB_TOKEN` は強力です。もしスクリプト内で `echo $CI_JOB_TOKEN` とかやってログに出すと、それはGitLab上に記録として残ります。

教訓: ログに出力するのは厳禁。デバッグが必要な場合は、`echo ${CI_JOB_TOKEN:0:5}` のように、先頭数文字だけ確認するようにしましょう。

③ ネットワーク構成の確認

もしGitLab Self-Managed版を使っているなら、サーバー間通信が許可されているか確認してください。Job Tokenはあくまで「認証」であり、「通信経路」を確保するものではありません。

—

さあ、次はあなたの番です

この手法を導入すれば、アクセストークンの期限切れに怯える日々や、権限管理の煩雑さから解放されます。

最初は「設定項目が多くて面倒だな」と感じるかもしれません。しかし、一度設計してしまえば、あとはシステムが勝手に安全な認証を行ってくれる。これこそが、DevOpsエンジニアが目指すべき「自動化された信頼」です。

まずは、小さな社内ツール同士の連携から試してみてください。その一歩が、あなたのチームをより強固なものに変えていくはずです。

何か詰まったら、いつでも聞いてくださいね。現場の壁を一つずつ、一緒に乗り越えていきましょう。