Investigate required rules/conditions/policies for Runner Management GraphQL endpoints
Problem statement
Currently, there are many HAML pages in the administration UI which are directly testing for conditions in order to determine if a functionality should be available/shown to the user. This leads to a tight coupling of view/backend logic and is no longer the best way to go about this problem.
A random example is testing for the :admin_pipeline
permission in order to determine whether to show the setup instructions for a group runner (but there are likely worse offenders).
Proposal
We should migrate towards using declarative policies instead (see also the GraphQL-specific docs), which will allow us to build rules and policies on top of the conditions for less brittle code.
This issue will serve as a discussion forum to distill the intended permission model in a single place, instead of an ad-hoc fashion on each MR.
The implementation work will be tracked under the &7275 (closed) epic.
Current relevant rules
Rule | Implemented | Access | Used in | Notes |
---|---|---|---|---|
read_runner |
admin | owned_runner |
runners /runner queries |
||
update_runner |
admin | owned_runner |
runnerUpdate mutation |
||
assign_runner |
admin | owned_runner |
POST /projects/:id/runners |
||
delete_runner |
admin | owned_runner |
runnerDelete mutation, Groups::RunnersController , DELETE /runners/:id
|
Note: In projects we may need additional permission to remove_project_runner , in the UI today maintainers can do both in a single operation. |
|
delete_runners |
admin |
runnerDeleteMany mutation |
Note: This is only available to admins since it could be prohibitive to check for permissions for individual runners when applying a filter. | |
register_runner |
admin | owned_runner |
Used via runner CLI, token validation is done. It may be equivalent to create_runner (?) |
||
use_runner |
(?) | Can this user run jobs on this runner? Are they restricted in some way? (see #35346, &6058) | ||
read_builds |
|
admin (will be expanded later) |
Can this user ever jobs on this runner? Used in the runner read-only view | |
register_project_runners |
|
project maintainer
|
Checking whether to show registration instructions in project runner page | Needed because we want to make register_group_runners owner-only, while register_project_runners will be allowed for project maintainers. Also in #349458 (comment 800853691)
|
read_group_runners |
|
group owner
|
group { runners } query |
TODO. Is reusing the read_runner rule sufficient for this? In our menu we check for read_group_* to decide if we show the some group entities. |
admin_group_runners |
|
group owner
|
Manage runners in groups | Currently implemented in HAML as a check for :admin_pipeline permission |
prune_group_runners |
|
admin | group owner |
Prune stale runners in groups | |
register_group_runner |
|
group owner
|
app/views/admin runner registration views. Possible future GraphQL mutation. |
Would need to take the :valid_runner_registrars application setting into consideration. See !64636 (comment 608307783)
|
register_project_runner |
project owner / project maintainer
|
app/views/admin runner registration views. Possible future GraphQL mutation. |
Would need to take the :valid_runner_registrars application setting into consideration. See !64636 (comment 608307783)
|
Tagging @fabiopitino @tmaczukin @grzesiek