Draft: Add token expiry configuration for runners
What does this MR do and why?
This change adds a token expiry configuration form to the Admin CI/CD settings, allowing admins to set an expiry time for runners that are newly registered.
It shows the expiry time of each runner in its detail page.
Pending tasks:
-
Add unit tests -
Improve UI text -
Add documentation for this feature (and link to it)
This change is behind "enforce_runner_token_expires_at" feature flag.
Screenshots or screen recordings
| Admin settings (/admin/application_settings/ci_cd) | Runner details (/admin/runners/XXX) |
|---|---|
 |
 |
How to set up and validate locally
I've listed instructions to validate in two sections
- Enable the feature
Feature.enable(:enforce_runner_token_expires_at) - Log in as admin
- Visit Admin -> Settings -> CI/CD
- Expand Continuous Integration and Deployment
- Set a runner expiration interval, such as
Instance runners expiration(minimum is 2 hours)
Frontend validation
- (In your console) register an (instance) runner and start it:
$ gitlab-runner register ...$ gitlab-runner run- Visit the runner details at Admin -> Runners -> New runner
- Confirm the runner has an expiry time.
E2E validation
Additionally, we can check that the entire E2E flow works, this is a bit more involved:
- Ensure your runner runner run 15.3 (or at least runs gitlab-runner!3209 (merged)), this is bleeding edge.
- (In your console) register an (instance) runner and start it:
$ gitlab-runner register ...$ gitlab-runner run- Wait for 75% of the expiration time to pass, if you selected 2 hours, the time is 90 minutes
- Confirm the runner has a new and updated expiry time, as the token has rotated.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #30942 (closed)
Edited by Miguel Rincon