Enforce expiration for runner authentication tokens and support automatic runner token rotation
Proposal
Currently, when a new GitLab runner is registered, while the registration token is easily rotatable, the runner authentication token lives indefinitely. We don't enforce a default expiration on runner authentication tokens. These tokens never expire.
Further, there are no restrictions on where a runner token is used from or explicit checks to that end, making it difficult to uncover theft. Stealing a runner token gives undue access not only to source code, but also sensitive variables that are sent along with the job request which can put other resources at risk.
MR !71607 (closed) begins to address the issue by providing a mechanism to enforce a lifetime over these runner tokens, but the user experience suffers in that there is manual intervention necessary to obtain a new token. As I mentioned in this comment, the authentication flow for a runner is not all too dissimilar from using OAuth where the registration and runner tokens are in some ways analogous to refresh and access tokens respectively.
The proposal is to:
- Enforce an expiration on runner authentication tokens in line with what is mentioned in the token management standard
- Modify the GitLab server:
- API to accommodate this OAuth-like token refresh model
- Monitoring to surface repeated, failed runner API requests
- Modify the GitLab runner to be aware of and leverage the above API to refresh its tokens
In this way, a user only performs the initial registration, but future refreshes are handled by the runner itself. Repeated failures would help alert the user or administrators of attempted unauthorized access or theft if the existing user's runner is no longer able to connect.