Investigate authentication handling for Container Virtual Registry to decouple from Dependency Proxy

Problem

Currently, Container Virtual Registry reuses the Dependency Proxy authentication service (Auth::DependencyProxyAuthenticationService) because both services live on the same host and use the same URL structure (/v2/...). This creates an unnecessary coupling between the two features.

As noted in !210622#note_2870902483:

From #549131:

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.

The current authentication flow is:

JwtController -> DependencyProxyAuthenticationService -> VirtualRegistries::ContainerController

Challenge

We need to figure out how to distinguish between requests for:

  • Dependency Proxy (/v2/...)
  • Container Virtual Registry (/v2/virtual_registries/container/:id/...)

Both use the same authentication mechanism, but they serve different purposes and should ideally be decoupled.

Goal

Investigate and propose a solution for handling authentication for Container Virtual Registry that:

  1. Allows us to distinguish between Dependency Proxy and Container Virtual Registry requests
  2. Removes the unnecessary coupling between these two features
  3. Maintains compatibility with Docker client authentication flows
  4. Doesn't break existing Dependency Proxy functionality

Acceptance Criteria

  • Document the current authentication flow for both Dependency Proxy and Container Virtual Registry
  • Identify the specific points where requests need to be distinguished
  • Propose one or more solutions for decoupling the authentication
  • Evaluate trade-offs of each proposed solution
  • Recommend a preferred approach with implementation plan

Related

Edited by 🤖 GitLab Bot 🤖