まずは結論
GitLab 161 以降で別プロジェクトの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 させたい場合は、オフにしましょう。
どういうことか?
GitLab CI/CD では、あらかじめ自分たちでビルドしたDockerイメージを同じ GitLab インスタンスの Container Registry に格納しておけば、特にレジストリの認証(docker login
)は明示的に行わないままいきなり利用することができます。
よくCI/CDで使うDockerイメージはあらかじめGitLab内に登録しておくと、別プロジェクトからいきなり参照したりして便利に使うことができます。(その際の裏で使われる認証パスワードが CI_JOB_TOKEN
にあたります。)
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.
これを解消するには
- 上記の設定自体をオフにするか
- 許可するプロジェクトをきちんと指定してあげる (こちらのほうが良い)
必要があります。当然後者のほうが推奨されています。
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時間ぐらいハマりました。みなさんは同じことにならないように気をつけましょう。
-
この記事は GitLab 16.2.7 にて検証しています ↩