Skip to content

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

Edited by 🤖 GitLab Bot 🤖