Pull security mirror test images through its parent group's proxy

Reuben Pereirarequested to merge
rp-security-mirror-direct-dependency-proxy into master

What does this MR do?

On the security mirror only, switches test:build-scripts and lint:build-scripts-shellcheck from CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX to CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX, so they pull through the mirror's parent group's dependency proxy instead of the top-level gitlab-org one. Canonical and the other mirrors are unchanged.

Project Proxy before Proxy after
gitlab-org/build/CNG (canonical) gitlab-org gitlab-org (unchanged)
gitlab-org/security/charts/components/images (security mirror) gitlab-org gitlab-org/security/charts/components

The jobs read a new DEPENDENCY_PROXY_IMAGE_PREFIX variable from a .dependency-proxy-image-prefix template. It's defined in the per-mirror include files that .gitlab-ci.yml already selects by CI_PROJECT_PATH: vault-public-secrets.yml sets the top-level prefix, and vault-security-secrets.yml sets the direct-group prefix.

Why

On the security mirror, master pipelines run as the push mirror's user, and CI_JOB_TOKEN carries that user's permissions. Pulling through the gitlab-org dependency proxy needs Guest on gitlab-org, which the mirror user doesn't have. Both jobs fail in prepare_executor with a 404 after about 3 seconds, and only pass when a human retries them. Example: https://gitlab.com/gitlab-org/security/charts/components/images/-/jobs/16728523271

https://gitlab.com/gitlab-com/gl-infra/infra-mgmt/-/merge_requests/3421 moves the push mirror to the cng-security-mirror-bot service account and gives it Guest on gitlab-org/security/charts/components rather than on gitlab-org. That group contains only the mirror, so the share grants nothing beyond the mirror itself. This MR points the mirror's jobs at that group's proxy.

Why only the security mirror

Docker Hub credentials are set per group and aren't inherited. gitlab-org has Docker Hub credentials. gitlab-org/build and gitlab-org/security/charts/components don't. Switching canonical to the direct-group prefix would have moved its cache misses from authenticated to anonymous Docker Hub pulls, so canonical keeps the top-level proxy.

The security mirror's pulls through gitlab-org/security/charts/components are anonymous on a cache miss. That's acceptable: the two images are pinned and haven't changed since they were added, and the mirror runs few pipelines. Each pull still requests a Docker Hub token and sends a HEAD for the manifest. Cached blobs are served without going to Docker Hub.

Nothing else changes: same images, same tags, same rules.

Status of https://gitlab.com/gitlab-com/gl-infra/infra-mgmt/-/merge_requests/3421

Applied and merged on 2026-10-22. The service account and its Guest share on gitlab-org/security/charts/components exist, so this change can be checked on the mirror as soon as it's mirrored.

Test plan

These jobs only run on MR pipelines when build-scripts/** changes, so this MR's own pipeline doesn't exercise the change. The CI lint API on this branch resolves both jobs' DEPENDENCY_PROXY_IMAGE_PREFIX to ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX} on canonical.

  • After merge, on canonical master: test:build-scripts and lint:build-scripts-shellcheck pass, and the job logs show the image pulled from gitlab.com:443/gitlab-org/dependency_proxy/containers/..., as before.
  • After the change is mirrored, on the security mirror's next master pipeline: it's triggered by cng-security-mirror-bot, both jobs pull from gitlab.com:443/gitlab-org/security/charts/components/dependency_proxy/containers/... and pass without a retry, and https://gitlab.com/groups/gitlab-org/security/charts/components/-/dependency_proxy lists bats/bats and koalaman/shellcheck-alpine.

Related issues

Related to https://gitlab.com/gitlab-com/gl-infra/delivery/-/work_items/22425

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion

Required

  • Merge Request Title, and Description are up to date, accurate, and descriptive
  • MR targeting the appropriate branch
  • MR has a green pipeline on GitLab.com
  • When ready for review, MR is labeled "~workflow::ready for review" per the Distribution MR workflow

Expected (please provide an explanation if not completing)

  • Test plan indicating conditions for success has been posted and passes
  • Documentation created/updated
  • Integration tests added to GitLab QA
  • The impact any change in container size has should be evaluated
  • New dependencies are managed with GitLab forked renovatebot
Edited by Reuben Pereira

Merge request reports