GitLab Access for CTO2B

When CTO2B sets up or maintains your CI/CD pipelines, we need an account in
your GitLab. This article explains which account we use, what it does, and
which permission level to grant so the setup does not stall halfway.

The accounts CTO2B uses

cto2bgeneric is owned and managed by CTO2B, and access to it is controlled
through CTO2B's own identity tooling. It is not a personal account belonging to
an individual engineer.

What the service account is used for

cto2bgeneric handles CI/CD and infrastructure-related access. In practice
that means cloning or updating repositories when the platform or an automated
process builds a container image, creating or adjusting .gitlab-ci.yml, and
reading pipeline logs when something fails.

Which permission level to grant

Maintainer is enough for almost everything: creating the pipeline
definition, viewing pipeline logs, and reading or setting CI/CD variables at
the project level.

Owner is required for group-level CI/CD variables. This is a GitLab rule,
not a CTO2B one — a Maintainer cannot view or set variables defined on a group.

This is the trap worth planning around. If any shared value your pipeline needs
lives at group level rather than being duplicated in each project — registry
credentials, a shared API endpoint — then Maintainer alone will let the setup
begin and then silently fail to complete. Grant Owner on that group up
front instead.

Reducing access afterwards

Depending on how the project ends up configured, the access level can often be
reduced once the setup work is finished. Raise a request when you would like us
to review what is still needed.

Related articles

• Access Requests
• Environments & Configuration