Restrict Role access in Forked Projects to Prevent License Exhaustion
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Proposal
Provide the functionality to prevent developers from elevating guest roles to developer roles within forked projects to avoid exhausting limited licenses in self-managed GitLab instances.
Description:
A customer manages access to developer roles in their self-managed GitLab instance via a controlled distribution list (DL) linked to LDAP. This allows administrators to efficiently manage and restrict developer roles in their top-level group and its subgroups.
However, the customer has identified an issue where developers can fork repositories and add guest users (who do not consume a license) as developers in their forked projects. This then elevates these guest users to licensed developers without admin approval, bypassing their intended access controls.
This has the following impact:
- Uncontrolled License Consumption: Users who were not intended to be developers start consuming limited licenses.
- Access Management Challenges: Forked projects exist in private namespaces, where our admin-controlled access policies do not apply.
The customer would like a mechanism to restrict such role escalations in forked projects. For example:
- Prevent users from assigning roles higher than "Guest" in their personal namespaces for forked repositories.
- Provide administrators with the ability to enforce or monitor role changes across all projects, including forks in private namespaces.
Proposed Solutions:
- Introduce an admin-configurable policy to limit the role users can assign in forked projects under their namespace.
- Option to disable role escalation entirely for forked repositories.