## 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](https://gitlab.com/gitlab-org/gitlab/-/work_items/543045#note_3239906158) as a solution to unblock enterprise customers who were impacted by the 18.9 access requirements change ([#580977](https://gitlab.com/gitlab-org/gitlab/-/work_items/580977)). ## 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](https://docs.gitlab.com/user/custom_roles/) 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 - Original feedback thread: https://gitlab.com/gitlab-org/gitlab/-/work_items/543045#note_3238926660 - Proposal comment: https://gitlab.com/gitlab-org/gitlab/-/work_items/543045#note_3239906158 - Related access change: https://gitlab.com/gitlab-org/gitlab/-/work_items/580977