@@ -48,6 +48,8 @@ The main identifiable problems are:
## 2. Data flow
The data flow for `docker login` is documented in [the container registry project](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/auth-request-flow.md#login). The equivalent requests using `curl` are documented below.
### 2.1. Authorization request that is send by `docker login`
```shell
@@ -108,6 +110,30 @@ There do not seem to be any theoretical problems with running GitLab container r
It seems that the service can be easily made routable to work well.
The practical complexities are around managing a complex service from an infrastructure side.
Since multiple Cells can be run on the same top-level domain, and the Docker client stores authentication tokens per-hostname, users may not be able to access resources from one Cell while logged in to another on the same hostname.
To authenticate with the container registry in a Cells environment, users will need to run:
```shell
docker login gitlab.example.com
```
The username can be anything; it is not used by GitLab's container registry. The "password" must be one of:
- Personal access token
- Project access token
- Group access token
Per the current [container registry authentication process](https://docs.gitlab.com/ee/user/packages/container_registry/authenticate_with_container_registry.html).
Note that **Deploy token** is listed as an available password for the container registry, but since these tokens are not routeable, they will only work with the legacy cell. The user's **GitLab username and password** can also be used to authenticate with the container registry, but this authentication method also does not contain routing information, so will only work with the legacy cell. For the first iteration, only routing to the legacy cell and default organization will be supported for all token types.
The docker client will then submit this username and password combination to the `/jwt/auth` endpoint in GitLab Rails using HTTP Basic Auth.
The Cells http router will be able to determine the correct Cell to route this request to by supporting HTTP Basic Auth requests using access tokens as the password. Support for this is [currently being built](https://gitlab.com/gitlab-org/cells/http-router/-/issues/138).
The returned JWT will contain enough information (something like `scope: cell-1`) for the Cells Registry Router to route the authenticated requests to the correct container registry / cell.
# TODO: Remove stage and group because the handbook doesn't need these attributes
stage:enablement
group:Tenant Scale
title:'Cells:DependencyProxy'
toc_hide:true
---
{{% alert %}}
This document is a work-in-progress and represents a very early state of the
Cells design. Significant aspects are not documented, though we expect to add
them in the future. This is one possible architecture for Cells, and we intend to
contrast this with alternatives before deciding which approach to implement.
This documentation will be kept even if we decide not to implement this so that
we can document the reasons for not choosing this approach.
{{% /alert %}}
[GitLab Dependency Proxy](https://docs.gitlab.com/ee/user/packages/dependency_proxy/) is a feature allowing storage of Docker container images in GitLab for use by CI jobs and end users. It acts as a pull-through cache of upstream registries such as Docker Hub, enabling faster image builds and avoiding restricted rate limits by upstream services.
As Dependency Proxy is a effectively a private image registry, it follows the same deployment pattern and challenges as the [GitLab container registry](container-registry.md).
## 1. Definition
The dependency proxy follows the same data usage and storage challenges as the [container registry](container-registry.md).
## 2. Data flow
The data flow for `docker login` is documented in [the container registry project](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/auth-request-flow.md#login). The equivalent requests using `curl` are documented below.
### 2.1. Authorization request that is send by `docker login`
Dependency Proxy can be run within a cell, similar to the proposal for the [container registry](container-registry.md).
## 4. Evaluation
Since multiple Cells can be run on the same top-level domain, and the Docker client stores authentication tokens per-hostname, users may not be able to access resources from one Cell while logged in to another on the same hostname.
To authenticate with the dependency proxy in a Cells environment, users will need to run:
```shell
docker login gitlab.example.com
```
Currently, [using your GitLab username and password is supported](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#authenticate-with-the-dependency-proxy) by this flow. In a Cells architecture, this will only work for the legacy cell and default organization, since the username / password combination is not routeable.
The username can be anything; it is not used by dependency proxy. The "password" must be a Personal Access Token from a user, service account, or CI job token. The docker client will then submit this username and password combination to the `/jwt/auth` endpoint in GitLab Rails using HTTP Basic Auth.
The Cells http router will be able to determine the correct Cell to route this request to by supporting HTTP Basic Auth requests using access tokens as the password. Support for this is [currently being built](https://gitlab.com/gitlab-org/cells/http-router/-/issues/138).
The returned JWT will contain enough information (something like `scope: cell-1`) for the Cells Registry Router to route the authenticated requests to the correct container registry / cell.
