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:
api
scope).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-bot
owned by the Engineering Productivity team, running various things. We're breaking this down into multiple dedicated service accounts.@gitlab-qa
owned by the Quality department, running QA-related automation.@gitlab-release-tools-bot
owned by the Delivery team, running delivery/release-related automation.@gl-build-trigger
owned by the Distribution group, triggering build-related pipelines.@gitlab-omnibus-mirror-bot
owned by the Distribution group, mirroring various dependency projects of the gitlab-org/omnibus-gitlab
project.gitlab-org/quality/triage-ops
, gitlab-org/gitlab-triage
owned by the Engineering Productivity team.@gitlab-bot
service accountPreviously, 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-bot
service 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.