Cleanup rotated config token?

[TJM]

One of the things we were looking into was the initial "admin" GITLAB_TOKEN. We would probably want to use maybe a group access token, or maybe a service account token (they are new, I haven't tried them yet). The problem we wanted to check on was whether that token itself is also managed/rotated. And if it is rotated, is it cleaned up when the config is "DELETE"(ed) or the module is disabled?

If the terraform module itself is not able to handle that, do you have any example terraform code to deploy the configuration? I am thinking it would be a gitlab provider to create the service account (circular dependency?), that would then set the "initial" GITLAB_TOKEN for the module. After that, it would have to rotate it's own token, somehow? (there is a rotation API)

side note: our infrastructure as code pipelines will create a "review" environment for each change to vault using terraform, and we want to ensure that we don't leave behind a bunch of "admin" tokens in gitlab after the review environment is stopped.

[ilijamt]

For a main token you have to use a PAT token, you cannot use a group token, it just doesn't offer the required permissions to be able to issue the tokens.

Vault plugin will not revoke the token if you do a DELETE on gitlab/config. The only way for the vault plugin to revoke a token is by setting auto_rotate_token is true and then issuing READ on gitlab/config/rotate, but then you have a new valid token.

For cleaning up old tokens, you will have to do the clean-up your self, as the last step of decommissioning the review environment. If you want to limit the amount of clean-up you can also create short admin tokens, don't know how long your review environments usually need to be up. If you create a token with 48h, Gitlab will automatically revoke the token, but yes the token will be available until the token expires.

To rotate the active Gitlab token, you can do it multiple ways. If you use the rotate endpoint in the plugin, you will no longer know what the token is, as it will only be stored inside Vault.

auto_rotate_token is false

• Terraform creates a main token
• Write to vault on gitlab/config
• Issue a rotate token READ on gitlab/config/rotate
• Terraform revokes the main token

auto_rotate_token is true

• Terraform creates a main token
• Write to vault on gitlab/config
• Issue a rotate token READ on gitlab/config/rotate
• Vault plugin will revoke old main token on successful rotate

[TJM]

Thanks! We need to cordon the token generation to top level groups, since each group will have its own vault cluster (with administrative access to it). I think we can try service accounts, hopefully they use PATs. The rotation part is what I hoped for, with the new enforced token rotations.