GitLab Workspaces personal access token rotation/expiration improvements
Currently GitLab Workspaces mints a Personal Access Token for 1 year or until the Workspace is terminated. Such a long-lived token may raise security concerns in some organisations.
For example, a security department may not like the long lifetime and require the Agent owners to massively decrease the time that a Workspace is allowed to run. This is annoying to users as it makes the experience worse.
Proposal
I can see several methods of solving this. These are somewhat ordered by their difficulty.
Configurable access token lifetime
Add a new field to the Agent Workspace configuration that allows the owner of the Agent to set the duration that the PAT is minted for. E.g., lowering it to 1 month or 1 week. This does ruin the user experience as the user will need to manually mint a token to push/pull repos or interact with the GitLab API.
Replace token on suspension
Workspaces are suspended after a period of time (I think the default is 36 hours). When the workspace is suspended GitLab could revoke the token and when the workspace is resumed, mint and inject a new one. This would require minimal changes to GitLab and could be done with a fairly small tweak to Rails and the Kubernetes manifests that it generates. It shouldn't require any changes to the Agent.
Self-renewing token
When creating the Workspace, mint the token with a 1-day (or something else short) lifetime.
Add a Deployment/CronJob that runs alongside the Workspace that uses the self-rotate API to renew the access token before it expires. This ensures that leaked tokens are quickly revoked before they can be used maliciously.