Group IP allowlist blocks GitLab.com hosted runners from using the container registry (pull and push), unlike clone and artifacts

Summary

On GitLab.com, enabling Restrict access by IP address on a top-level group breaks container registry access (pull and push) from GitLab.com hosted runners, unless every hosted runner egress IP is added to the group allowlist. This contradicts the documented behavior that group IP restrictions do not block hosted runners. The instance-wide globally allowed IP ranges do not cover registry traffic.

Steps to reproduce

  1. On GitLab.com, create a project in a top-level group with a CI job on a hosted runner that pulls from or pushes to registry.gitlab.com (for example a Docker build and push).
  2. Confirm the job passes.
  3. In the top-level group, enable Settings > General > Permissions and group features > Restrict access by IP address and allow only your own desktop or VPN range.
  4. Re-run the job.

Current behavior

git clone and artifact transfer still work, but registry access fails. Pulls fail with:

failed to pull image "registry.gitlab.com/<group>/<project>/<image>:<tag>" ...
denied: requested access to the resource is denied

Pushes from the job also fail. Retries can appear to succeed intermittently, depending on which region and egress address the runner VM uses.

Why it happens

Per the analysis in support-team-meta#7873:

  • Clone and artifacts reach Rails through the internal CI gateway as a 10.x address, which the globally allowed 10.0.0.0/8 covers.
  • The registry token request goes to gitlab.com/jwt/auth over the public internet, from the runner VM's public Google Cloud address. 10.0.0.0/8 cannot match it, so the group restriction applies and jwt/auth issues a token with an empty access claim. The registry then refuses the request (HTTP 200 from jwt/auth, not 403).

This is not new, but the hosted runner fleet now falls back from us-east1 to us-east5, us-east4 and us-central1, so allowlists that cover only us-east1 fail more often.

Expected behavior

The documented contract holds for the registry too: group IP restrictions do not block hosted runners for GitLab.com, so jobs can pull and push registry images without the group allowlisting runner IPs.

Impact

Any GitLab.com group that uses the IP allowlist and the GitLab container registry from hosted runners is affected. The only workarounds weaken or defeat the control:

  • Allowlist Google Cloud region ranges (about 18 IPv4 prefixes for us-east5 alone, about 228 across the four regions). This admits every tenant in those regions and must track fleet changes.
  • Use group or project runners with a fixed egress IP.

In practice, the group IP allowlist cannot be combined with hosted runners and the GitLab.com registry without these trade-offs.

Proposal

Make the registry token flow for hosted runner jobs go through the same internal path as clone and artifacts, or otherwise exempt it in the same way. Update the docs to list the registry as an exception in the meantime.

Related

Edited by 🤖 GitLab Bot 🤖