Introduce `read_virtual_registry` custom role ability

Summary

Introduce a read_virtual_registry custom role ability at the group level to allow admins to grant virtual registry read access without broader group visibility.

This was proposed in this comment as a solution to unblock enterprise customers who were impacted by the 18.9 access requirements change (#580977 (closed)).

Problem

After the 18.9 upgrade, virtual registry access now requires top-level group membership. This broke enterprise customers using SAML group-based access models with strict team isolation, where:

  • Users are not granted access at the namespace level; access is managed via SAML group links at the subgroup level.
  • Strict need-to-know principle: members of one team must not see or be aware of other teams.
  • Authentication is OIDC-based with short-lived credentials only — no personal/group/project access tokens.

Existing workarounds are not viable:

  1. Adding users as Guest to the top-level group — exposes all private subgroup names/structure, violating team isolation requirements.
  2. Deploy tokens / group access tokens / service accounts with PATs — ruled out by credential policy.
  3. Separate top-level group for the virtual registry — requires significant migration effort at scale.

Proposed Solution

Introduce read_virtual_registry as a new custom role ability at the group level.

The setup would look like:

  1. Add all users to the top-level group at Minimal Access (grants no visibility into subgroups or projects).
  2. Create a custom role based on Minimal Access with read_virtual_registry enabled.
  3. Assign that custom role to those members.

This addresses all three customer constraints:

  • Team isolation preserved — Minimal Access does not expose subgroup names or structure.
  • No deploy tokens/PATs needed — applies to existing OIDC-authenticated user identities.
  • No migration required — works within the existing namespace structure.

Current State

A PoC has been drafted locally and works as expected. The code change is relatively small — a single YAML definition that hooks into the existing custom roles framework.

References

Edited by 🤖 GitLab Bot 🤖