<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=378191) </details> <!--IssueSummary end--> ### Release notes - Placeholder for release notes ## Problem to Solve Organizations using GitLab need centralized control over their CI/CD build infrastructure, but the current permissions model ties runner registration rights to general project and group roles. When users are granted Owner or Maintainer access to subgroups or projects for legitimate development purposes, they automatically gain the ability to register their own runners — a capability that many organizations never intended to grant. This creates a fundamental governance gap: there is no way for a top-level group administrator to enforce a policy that only centrally managed, approved runners are used across their organization's groups and projects. The only existing control is at the instance-wide admin level, which is unavailable to group-level administrators and irrelevant for SaaS customers who don't have instance-level access. As a result, teams can bypass organizational security controls, compliance requirements, and operational standards. In the community contribution [Allow admins to limit registration of project and group runners](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61407) we added a feature that enables administrators to restrict registration of runners at the group and project levels. ### Proposal A group-level setting that allows top-level group Owners to disable runner registration for all subgroups and projects within their hierarchy. When enabled, users with Owner or Maintainer roles at lower levels would retain their existing development permissions but would not be able to register new runners. This setting should cascade down through the group hierarchy, providing a single point of enforcement for the entire organization. ### Intended users - [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer) - [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) ## Problem Validation | Customer | Problem to Solve | |----------|------------------| | https://gitlab.my.salesforce.com/0016100001Eo2GWAAZ <br>[customer comment](https://gitlab.com/gitlab-com/account-management/commercial/helpsystems/-/issues/55#note_1136496629) | Is there a way to restrict registration in addition to the settings page at the group and project level being visible only to group owners and project maintainers? We don't want anyone other than DevOps/admins to be able to register runners otherwise we'll have teams running amok building their own shadow DevOps processes. Some of the teams will have their own Owner/Maintainer for their subgroups or projects for various reasons but that shouldn't give them the ability to start attaching their own build infrastructure at will without our involvement. | | | | <!--### Feature Usage Metrics How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it? Create tracking issue using the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md-->