Review access to /runners/all API endpoint

Overview

A GitLab Premium self-managed customer recently wrote in to Support asking about permissions for the Runners API. After some testing and back and forth, it was determined that the user in question couldn't access details for instance-level runners, when trying to hit the API endpoint with these parameters:

https://example/api/v4/runners/:id/jobs?status=running

This was resolved by bumping the user's access to auditor. However, at this level of access, the user in question still doesn't have access to the endpoint for all runners:

gitlab.example.com/api/v4/runners/all

Our documentation states that this is limited to administrators. Our customer thinks that, for her particular use-case, it would be very useful for auditors (or others -- see below) to gain access to the endpoint in question. This user's role is to provide internal tooling and automation for her teammates/co-workers and got a request from them recently:

"...a read-only sudo-not-required viewer/dashboard (of all of our runners) would be really nice, we've got multiple repos vying for access to (a particular runner) and if we could view status we could inform each other about kicking off runs"

The customer said, in her own words:

I've put together a simple script that calls the API and populates an internal web page with runners and detailed information. However, since I'm not a GitLab admin, this is where the challenges arise. I don't need full administrative access, I'm just trying to get data so we can make decisions.

A non-admin user with full read_api access would easily clear the multiple smaller obstacles that we encountered. Or perhaps a user type is not the optimal way to do it. There are personal, project, and group tokens. Maybe an instance token that is read-only API and created/granted by an admin.

In short the customer is looking for a way to get details of all runners, instance-level or otherwise, to make things easier for her team, without necessarily getting administrator access, as she doesn't need it beyond this particular task. As such, perhaps we can review what access should be needed to access the /runners/all API endpoint specifically, and other runner-related details endpoints as well.

Problem(s) to solve

  • A non-admin user needs to be able to see the CI/CD job queue status of instance-level runners to make decisions about when to start CI/CD jobs so that they do not conflict with other projects vying for time on a specific runner.

Proposal

Edited by Pedro Pombeiro