Prevent a shared GitLab runner from reusing another project’s private image without a registry check

The if-not-present pull policy can cross an authorization boundary through the local image cache.

Source facts

GitLab’s runner security guide describes a private-image risk on shared runners. One user’s authorized job can pull an image into the runner’s local cache. A later user without registry access can request that image and receive the cached copy when the pull policy is if-not-present. GitLab recommends always for mixed-trust runners where users may request registry images, and reserves if-not-present for trusted dedicated use. The guide also distinguishes never for an administrator-controlled set of images already present on the runner.

Source: GitLab — Runner security.

Applicability

This concerns self-managed GitLab runners using the relevant container executors and pull policies. It is an image-access review, not a claim that one pull-policy setting provides complete job or host isolation.

DSE recommendation

DSE recommends documenting which users and projects share each runner and who controls image selection. For mixed-trust use, require an appropriate registry authorization check instead of silently trusting a cached private image. For a deliberately fixed image set, review the administrator-maintained model separately. Inspect runner configuration, allowed policies, and job overrides together. Keep credential helpers and host-side registry configuration in the broader runner security review, and consider dedicated execution capacity for workloads with incompatible trust requirements.

Verification

Using a disposable private image and two test identities, verify the chosen policy with a warm cache and with no cache. Confirm that an identity lacking registry permission cannot obtain the cached private image through the shared runner. Remove the test image and credentials afterward.

Official reference

GitLab — Runner security. Reviewed October 15, 2026.