Token management is crucial in providing authentication and authorization within various systems and subsystems used by GitLab. The token overview will assist in identifying the tokens used in GitLab. Refer to the Token Management Standard for approved token usage and distribution.
Automations for the
gitlab-org group and projects under it can be split into three categories:
These guidelines ensure consistency for Engineering automation using approved secure patterns aligned with least privileged access principle.
Automation that opens a merge request in projects under
gitlab-org shall apply the
~"automation:bot-authored" label for clearer measurements for bot authored MRs that may cause an impact to Engineering PIs.
Never reuse an existing token for your own automation, as this makes it harder to track what a token is used for. It also increases the number of changes required if the token is revoked.
By default, and when possible, create a new project access token for any API automation, and follow these guidelines:
Project access tokens have a few known limitations, but dogfooding them can only help us improve the feature.
Create a new project deploy token for repository, packages, or container registry automation.
Follow the same guidelines as for the project access tokens above.
For cases where automation is applied at the group level or across multiple projects, and where the Maintainer permission is required to perform the automation (for example, to post restricted quick actions), you can request a new service account that will be owned by a specific team.
GitLab uses automation to streamline engineering processes, such as:
@gitlab-botowned by the Engineering Productivity team, running various things. We're breaking this down into multiple dedicated service accounts.
@gitlab-qaowned by the Quality department, running QA-related automation.
@gitlab-release-tools-botowned by the Delivery team, running delivery/release-related automation.
@gl-build-triggerowned by the Distribution group, triggering build-related pipelines.
@gitlab-omnibus-mirror-botowned by the Distribution group, mirroring various dependency projects of the
gitlab-org/gitlab-triageowned by the Engineering Productivity team.
Previously, we had a single
@gitlab-bot service account that we used for almost all of our automated processes.
This had two main drawbacks:
We are in the process of:
@gitlab-botservice account credentials to an Engineering Productivity 1Password vault, to stop the self-service of creating tokens.
@gitlab-bot's tokens to project access tokens where possible, and to specific service accounts for the other cases.