馃帹 Design: Include runner authentication token expiration option for an Instance
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Release notes
Problem to solve
!71607 (closed) adds an option in the UI to make the authentication token for runners expire after a set amount of time. This issue is specific to evaluating how to do so for runners within an Instance.
The options include setting an expiration interval for the following runner types:
- shared (instance) runners
- group runners
- specific (project) runners
Setting the expiration interval is distinct per runner type, but once it is set, it will apply to anywhere X type of runners are used in the admin's organization
Runner registration and authentication keys need to be rotated periodically (e.g., daily), or at least gitlab should provide support to enable key rotation. The registration token used for attaching runners is visible to users via the browser, and will allow an arbitrary runner which has that token to register. During registration, the runner gets an authentication token which it can store locally and reuse that authentication token on restart. Because both the registration token and authentication token live until manually revoked, old copies of these tokens can be compromised and used, e.g., by an ex-employee, resulting in arbitrary code running from arbitrary locations masquerading as runners.\
--> See #30942 (closed) for more details.
Intended users
User experience goal
This user should be able to use the functionality set out in this MR !71607 (closed) in the Admin UI to set a runner authentication token to expire after a certain amount of time, if desired.
User stories:
- If an admin sets an expiration interval for shared runners, it will only apply to shared runners, not group runners or project runners.
- If an admin sets an expiration interval for group runners, it will apply to all group runners on the site, not shared runners or project runners. All group admins will see the "maximum expiration interval" warning in their settings.
- If an admin sets an expiration interval for project runners, it will apply to all project runners on the site, not shared runners or group runners. All project admins will see the "maximum expiration interval" warning in their settings.
Proposal
We need to figure out where is best to place this configuration option within the Admin view. We have ongoing work to remove the card that lives above the table in #299509 (closed).
One idea for MVC is to move this into Admin>Settings and create a new Runner section for this field/other configurations that are related to runner authentication tokens.
Further details
Permissions and Security
Documentation
Availability & Testing
Available Tier
What does success look like, and how can we measure that?
What is the type of buyer?
Is this a cross-stage feature?
Links / references
Current MR for this feature in the UI: !71607 (closed)
MR for API: !69561 (merged)
Original feature request: #30942 (closed)