[小ネタ] GitLab 16以降のCI/CDで他プロジェクトのContainer Registryからイメージを何故かpullできないと思ったら…

まずは結論

GitLab 16¹ 以降で別プロジェクトのContainer Registryから 下記の認証エラーによりイメージを何故かpullできない と思ったら…

Authenticating with credentials from job payload (GitLab Registry)
Pulling docker image foobar.example.net/your/project/image:latest ...
WARNING: Failed to pull image with policy "always": Error response from daemon: pull access denied for foobar.example.net/your/project/image, repository does not exist or may require 'docker login': denied: requested access to the resource is denied (manager.go:237:0s)
ERROR: Job failed: failed to pull image "foobar.example.net/your/project/image:latest" with specified policies [always]: Error response from daemon: pull access denied for foobar.example.net/your/project/image, repository does not exist or may require 'docker login': denied: requested access to the resource is denied (manager.go:237:0s)

Dockerイメージがpullされる側の別プロジェクトの Settings → CI/CD → Token Access → Allow access to this project with a CI_JOB_TOKEN が適切な値になっているか見直しましょう！！

↑ これがオンになってませんか？今まで通り、別のリポジトリのCIから pull させたい場合は、オフにしましょう。

(2025/07/17 追記) GitLab 18以降はこの機能をオフにすることはできず、明示的にグループまたはプロジェクトを許可する必要があります。

The Limit access from this project setting is disabled by default for all new projects and was removed in GitLab 18.0.
https://docs.gitlab.com/ci/jobs/ci_job_token/#limit-your-projects-job-token-access-removed

どういうことか？

GitLab CI/CD では、あらかじめ自分たちでビルドしたDockerイメージを同じ GitLab インスタンスの Container Registry に格納しておけば、特にレジストリの認証(docker login)は明示的に行わないままいきなり利用することができます。

よくCI/CDで使うDockerイメージはあらかじめGitLab内に登録しておくと、別プロジェクトからいきなり参照したりして便利に使うことができます。（その際の裏で使われる認証パスワードが CI_JOB_TOKEN にあたります。）

client_project/.gitlab-ci.yml

test:
  stage: test
  image:
    # 自作Dockerイメージ
    name: mygitlab.example.com/mygitlab_group/builder_image_project:latest

ただし、この動作がGitLab 16から変更されたらしく、新規作成したプロジェクトのデフォルト設定として別プロジェクトからのイメージpullを拒否するようになってしまいました。

16になる前に作成したプロジェクトであれば設定はデフォルトはオフになっていますが、16以降に作成したプロジェクトはオン（自プロジェクト以外からのpullは禁止）になっています。

By default, the allowlist of any project only includes itself.

これを解消するには

• 上記の設定自体をオフにするか (18から使えません)
• 許可するプロジェクトをきちんと指定してあげる （こちらのほうが良い）

必要があります。当然後者のほうが推奨されています。

It is a security risk to disable this feature, so project maintainers or owners should keep this setting enabled at all times. Add projects to the allowlist only when cross-project access is needed.

https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#allow-access-to-your-project-with-a-job-token

明示的に許可するプロジェクトのホワイトリストを指定すればいいわけですが、内部的なGitLabだったらそこまでリスクが顕在化することもないので、いっそ今まで通りのレベル（オフ）でもいいと思います。

これで地味に1時間ぐらいハマりました。みなさんは同じことにならないように気をつけましょう。

1. この記事は GitLab 16.2.7 にて検証しています ↩