Feature Proposal: Optional vault URL for Personal/Group/Project Access Tokens and for Group/Project Deploy Tokens
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Proposal
In order to automatically rotate personal, group and project tokens, we would like to have the ability to add a "vault link" to each token we create. On token rotation via API, the vault link should be preserved by default, if not provided in the request.
An optional description and vault link would be useful for project and group deploy tokens as well, if the deploy tokens have an expiry date and a copy of the token is stored in an external vault, where it needs to be updated when a new deploy token is created with the same name, which is similar to the rotation of access tokens.
We would like to use the vault link to store a reference per token to an external secret (like AWS Secrets Manager Secret ARN) which can be accessed via GitLab JWT OIDC, or a URL to a specific GitLab group or project CI/CD variable, or an external secrets provider secret, where the token is stored outside of GitLab and the external secret value needs to be updated, when the GitLab access token is rotated. The vault link would specify a worldwide unique resource identifier (secret location) where to store the new token when the token is nearing expiration and a new token has been created.
For security audit purposes, it would also be very handy to have a security overview or dashboard with all personal, group, and project tokens, including their names, descriptions, vault links, last use, and expiry times.
Workflows
Generation of token documentation for audit purposes
- we list all personal secrets: user, creator, expiry, permissions, description, vault link
- we list all group secrets: group, creator, expiry, permissions, description, vault link
- we list all project secrets: project, creator, expiry, permissions, description, vault link
- we list all project deploy tokens
- we list all group deploy tokens
- we generate an overview on all access and deploy tokens to allow for security reviews of all tokens, their description and vault location
The "vault link" points to the storage location of the token/secret to enable automated jobs to automatically rotate and update the token in the vault of a secrets provider.
Examples for possible secrets providers for vault link are:
- AWS Secrets Manager Secret (GitLab JWT id_token, AWS IAM gitlab.com ID provider, IAM Auth Role)
- Google Secret Manager Secret
- HashiCorp Vault Secret
- GitLab CI/CD Variables
Automated rotation of tokens using GitLab CI/CD jobs
- we store secrets in masked CI/CD variables or preferably encrypted in AWS Secrets Manager
- we detect that a GitLab token will expire soon
- a GitLab token rotation job looks up where the expiring token is stored (vault link)
- a GitLab token rotation job automatically rotates and stores the updated secret (via GitLab id_token mechanism) in the external vault
The "vault link" helps to identify where exactly the secret value of the token is stored.
Without a link between the access token or deployment token in GitLab.com and the token in the CI/CD variable or external secrets provider, it is difficult, if not impossible, to locate and rotate the token in the corresponding vault in a fully automated manner.