Sign in or sign up before continuing. Don't have an account yet? Register now to get started.
Register now

Container image virtual registry: push/pull endpoints API

🗒️ Goal

This issue is for the API endpoints required so that clients can pull objects from the container image virtual registry.

We have a few challenges:

  • Authentication. Docker clients will use a specific login flow. For this part, we don't have any choice given that the virtual registry lives in the same host than the dependency proxy for container images. Thus, we have to reuse the dependency proxy authentication service.
  • Fixed url structures. Docker clients will not use a prefix and compute accessed urls from there. Instead, it will take the host, append v2 and then append whatever we have on the docker command. Thus, we can't really target the GitLab API endpoints (/api/v4) because docker clients, will use a v2 prefix: /v2/api/v4. This doesn't look great. Instead, we're going to use the same approach as the dependency proxy: use rails controllers mounted on the correct urls.
Route Notes
GET /v2/virtual_registries/containers/:registry_id/*image/blobs/:sha Get a blob from the registry object
POST /v2/virtual_registries/containers/:registry_id/*image/blobs/:sha/upload The upload endpoint required for the workhorse assisted uploads
GET /v2/virtual_registries/containers/:registry_id/*image/manifests/:sha Get a manifest from the registry object
POST /v2/virtual_registries/containers/:registry_id/*image/manifests/:sha/upload The upload endpoint required for the workhorse assisted uploads

Notes:

  • We have mainly two GET endpoints.
  • Since we're going to use the dependencyproxy logic of workhorse, we will need an upload endpoint to upload the file from the upstream. We don't need any specific suffix here and /upload will work well.
  • Note that, contrary to the dependency proxy for container images, we don't have the /authorize endpoint. We will use one recent update from the dependencyproxy logic: the instructions received by workhorse will already include the data that /authorize would return.
  • On the dependencyproxy options, make use of the RestrictForwardedResponseHeaders option to build an allow list of headers that can be forwarded from upstreams. (The precise allow list needs to be investigated).

🛠️ Implementation plan

  • Container image virtual registry: database models (#548783 - closed) • Adie (she/her), Radamanthus Batnag • 18.5 • Needs attention
  • Container image virtual registry: cache entry s... (#549103 - closed) • Radamanthus Batnag • 18.5 • On track
  • Container image virtual registry: upstream serv... (#549104 - closed) • Adie (she/her) • 18.4
  • Container image virtual registry: handle file r... (#549134 - closed) • Adie (she/her) • 18.6
  • Container image virtual registry: manage APIs (... (#548794 - closed) • Adie (she/her) • 18.5 • On track
  • Container image virtual registry: push/pull end... (#549131 - closed) • Radamanthus Batnag • 18.8 • At risk 👈
  • Container image virtual registry: performance r... (#549136) • Radamanthus Batnag • 18.10
  • Container image virtual registry: documentation... (#549138 - closed) • Adie (she/her) • 18.6
  • Container image virtual registry: additional fe... (#549470) • Unassigned • Backlog
Edited Oct 10, 2025 by 🤖 GitLab Bot 🤖
Assignee Loading
Time tracking Loading