CI/CD → Runners page returns "No runners found" if user does not explictly have the "Owner" role directly in the group, but instead is an "Owner" via an invited subgroup
Status update (2023-11-17)
This will be solved by Allow developers invited through group to read ... (!137041 - merged) • Pedro Pombeiro • 16.7
Summary
When viewing the CI/CD → Runners
page / attempting to View and manage group runners within a group as a user that has the Owner
role via inheritance rather than directly in the group, the Runners info table simply outputs No runners found
instead of populating. The Online runners
, Offline runners
and Stale runners
values will still be populated.
Steps to reproduce
Example scenario:
-
Create a group and register a group runner to it.
-
Configure a group with SAML/SSO, and set the Default membership role for provisioned users to
Minimal Access
.- In this example the group is
jr-ultimate-test
on GitLab.com SaaS.
- In this example the group is
-
Create a subgroup with the
Max Role
set toOwner
, and then invite this group into the previously created group.- In this example, the subgroup
account-owners
was created underneathjr-ultimate-test
, and then invited to thejr-ultimate-test
group's member list viaGroup Information → Members → Invite a group
.
- In this example, the subgroup
-
Provision a new user to the top level group. They should automatically be assigned a
Max Role
ofMinimal Access
the reflect the Default membership role set earlier.- In this example, the user
jrtesting
was provisioned into thejr-ultimate-test
group, which is the top level group.
- In this example, the user
-
Invite the user to the created subgroup, with the
Max Role
value set toOwner
.- In this example, the user
jrtesting
was added to theaccount-owners
group.
- In this example, the user
-
At this point, the created user will still appear to have a
Max Role
ofMinimal Access
at the top level group, however due to the inheritance situation, they'll be able to perform actions from the top level group and downwards that are normally restricted to users with theOwner
role. -
If the created user now tries to view the
CI/CD → Runners
page for this group / View and manage group runners, they'll see a count of runners, but the actual table of Runners will be missing, and simply show a message that statesNo Runners found
. Despite this, the user can still register new runners on the screen, but they can't actually see them, manage them, delete them etc. -
If the created user has their
Max Role
changed to be anOwner
directly in the top level group (and they'd have permissions to make this change themselves at this point), then the table of Runners will populate as expected.
What is the current bug behavior?
The ability to View and manage group runners from the CI/CD → Runners
page appears to be restricted to only users with a direct Owner
role in the group. Owner
permissions via an inheritance situation does not seem to work for this ability, however it does seem to work for other features across GitLab, so the user experience becomes inconsistent.
To add to the inconsistency, a user in this situation can still register new runners into the group, but they cannot actually see them, manage them, delete them etc.
What is the expected correct behavior?
From a user perspective, if this kind of group role arrangement allows a user to perform actions restricted to the Owner
role for other GitLab features, then this should also be the case for the CI/CD → Runners
page.