GitLab Access Tokens effektiv nutzen

Das Managed-Services-Team von Eficode unterstützt viele unserer Kunden dabei, GitLab korrekt bereitzustellen. Dabei sind zahlreiche intensive Gespräche über Best Practices für Identity and Access Management (IAM) entstanden. Ein wiederkehrendes Thema ist die richtige Nutzung der verschiedenen Tokens, die GitLab anbietet.

Kalle Sirkesalo

Field CTO

Kalle sits at the intersection of executive strategy and engineering reality. He works directly with CTOs and engineering leaders to translate business pressures — speed, compliance, ROI — into technical decisions that actually hold. His job is to make sure what we recommend is something your organization can actually execute.

Ich finde, Tokens verdienen einen eigenen Blogbeitrag: Sie sind ein leistungsstarkes Werkzeug, erfordern aber ein gewisses Verständnis, um optimal eingesetzt zu werden.

Die sieben Säulen der Tokens

Meiner Einschätzung nach gibt es zwölf verschiedene Tokens, die sich in mehrere Kategorien unterteilen lassen: Personal, Project, Group, Runner, Integration, Admin und Global. Der Nachteil dieses fein abgestuften Systems ist, dass es viel zu viele Möglichkeiten bietet, eure IAM-Profile zu automatisieren.

Die folgende Tabelle gibt einen Überblick darüber, wie die verschiedenen Token-Typen eingesetzt werden sollten:

Category	Token name	Description	Recommendation	Who can modify
Personal	Personal access token	Usage of SSO platforms (e.g., Azure AD), enables API usage, enables usage of Git in SSO if SSH is prevented	Should always be used instead of username+password for API calls.	Users themselves
Project	Project access token	API access and capability to push to a project; meant for automatic management of project and API access	In monorepo environments, these tokens enable easy access to many repositories and their central management. Capability to push tags to a Git repository.	Project Owner & Maintainer
Project	Deploy token	The default way of reading Git and pushing/pulling from Docker & package registry with no pushing to Git repository	We recommend this for monorepo projects needing to read Git repository outside of GitLab and capability to push/read binaries.	Project Owner & Maintainer
Group	Group access token	API access and capability to push to project, meant for automated management of the whole group of projects and API access	In multirepo environments, these tokens enable easy access to many repositories and their central management. Capability to push tags to a Git repository.	Group Owner & Maintainer
Group	Group deploy token	The default way of reading Git and pushing/pulling from docker & package registry without pushing to a Git repository. Good for multirepo projects as they allow using the same token for many Git pulls.	Recommendation for multirepo projects needing to access Git repositories outside of GitLab and capability to push/read binaries.	Group Owner & Maintainer
Global	Access token	Grants global admin permissions for all repositories and APIs based on scopes.	Should not be used unless you really need to manage the whole instance via API.	Global admin
Global	Deploy token	Grants global admin permissions for all repositories for reading.	Should not be used unless you really need to read every Git repository in the instance.	Global admin
Project and Group	Trigger tokens	Allows CI/CD pipelines to be triggered remotely. Allows you to do a POST request to GitLab to trigger a CI/CD job without any other authentication.	This token is very powerful for creating separation of duties or automating tasks via GitLab Jobs.	Project Owner, Group Owner & Maintainer
Integration	Oauth 2.0	Allows you to create authentication between many services.	Most of our customers need this for Jira integrations	Group owner and Global admin
Integration	JSON Web Token (JWT)	Allows you to create secret management between a multitude of services.	For example, to be used for integration to Hashicorp Vault	Group owner and Global admin
Runner	Runner Registration	Allows runners to register to GitLab to be used	Should be only used to integrate the GitLab runners	Group Owner, Project Owner, Global admin
Admin	Impersonation token	A token meant to be used by the administrator to see what a given user sees and can see to debug issues.	You should aim never to use these tokens, but when you have a question about visibility and need to debug, this is a very powerful token to help in admin work.	Global admin

Warum ich Tokens liebe

Bei der Erstellung moderner IAM-Modelle beginnen wir in der Regel damit, Multi-Factor Authentication (MFA) und Single Sign-On (SSO) durchzusetzen und die Anzahl technischer Accounts (auch Service Accounts genannt) in Unternehmen zu begrenzen. So behalten wir die Kontrolle über den technischen Zugriff auf Systeme. Diese Praxis verhindert, dass APIs nur mit einer Kombination aus Benutzername und Passwort oder über einen technischen Account genutzt werden, den jemand erstellt hat und der am Ende etwas zu weitreichende Zugriffsrechte besitzt.

Wir brauchen eine komfortable und sichere Möglichkeit, Benutzer zu identifizieren und Zugriffe zu steuern. Genau dafür sind Tokens da: Sie machen das Zugriffsmanagement sehr einfach – selbst wenn wir das System nicht mit Active Directory oder einem vergleichbaren LDAP-Provider integrieren, dessen aktive Passwörter mit dem System synchronisiert werden. Tokens ermöglichen es Benutzern, Schritte zu automatisieren, ohne technische Accounts und die zusätzliche Komplexität, die sie für das IAM-Modell mit sich bringen.

Ihr müsst euch jedoch um eure Tokens kümmern. Wenn Tokens zu lange ungenutzt herumliegen, führt das immer zu unangenehmen Überraschungen. Wir empfehlen in der Regel, dass alle Access Tokens nach spätestens 90 Tagen ablaufen. Bei längeren Laufzeiten erinnert sich meist niemand mehr daran, dass die Tokens veraltet sind. Außerdem gibt es wenig Anreiz, ihre Nutzung mit Hashicorp Vault oder einer vergleichbaren professionellen Lösung für Secret Management zu automatisieren, wenn alte Tokens beliebig verwendet werden können.

Tokens sollten außerdem regelmäßig genug rotiert werden, um unbefugten Zugriff durch Leaks zu verhindern und sicherzustellen, dass die Teams, die sich mit euch integrieren, das Abrufen der Tokens automatisieren.

Tokens richtig verwenden

Tokens zu verwenden ist nicht schwierig, aber ihr müsst darauf achten, die richtigen Verfahren und die korrekte Syntax zu nutzen.

Die folgende Tabelle enthält Hinweise und Beispiele für die korrekte Verwendung von GitLab-Tokens. Auch die GitLab-Dokumentation zur Erstellung von Tokens ist gut (Links in der Tabelle).

Token	Command examples
Trigger token	`#export SECURE_TRIGGER_TOKEN=<token> #export MY_PROJECT_ID=<your project id> #curl --fail --request POST --form token=$SECURE_TRIGGER_TOKEN --form ref=main "https://gitlab.example.com/api/v4/projects/$MY_PROJECT_ID/trigger/pipeline`
Personal Access token	Token used normally as a password (screenshot below)
Project/Group access token	Username: `Token name` Password: `Token secret` (screenshot below)
Deploy token	Username: Can be changed in UI, but defaults to `gitlab+deploy-token-{n}` Password: `Token secret` (screenshot below)
JWT tokens with Vault	JWT token addition to Vault `vault write auth/jwt/config \ jwks_url="https://gitlab.example.com/-/jwks" \ bound_issuer="gitlab.example.com"` GitLab CI runner: `build-job: stage: build secrets: DATABASE_PASSWORD: vault: db_admin/value@example2 script: - echo "$DATABASE_PASSWORD"`

Screenshots von Tokens und Befehlen

Personal Access Token

Project-/Group-Access-Token

Benutzername: Token name

Passwort: Token secret

Deploy Token

Benutzername: Kann in der Benutzeroberfläche geändert werden, standardmäßig ist jedoch gitlab+deploy-token-{n} festgelegt

Passwort: Token secret

Denkt an das Prinzip der minimalen Berechtigungen!

GitLab bietet viele Token-Typen. Standardmäßig solltet ihr jedoch immer die folgende Reihenfolge berücksichtigen, wenn ihr entscheidet, welche Tokens ihr benötigt, um die Prinzipien der minimalen Berechtigungen einzuhalten:

Personal Access Token
Project Deploy Token
Group Deploy Token
Projekt-Token
Gruppen-Token
Globaler Deploy-Token
Globaler Access-Token

Erste Schritte mit Tokens

Meine Empfehlung: Arbeitet mit euren Teams zusammen, um herauszufinden, wie ihr GitLab-Tokens in eurer Organisation am sinnvollsten einsetzt. Hoffentlich vermittelt euch diese kurze Einführung jedoch einen Eindruck von den vielen Möglichkeiten, die GitLab bietet.

Wenn ihr mehr Orientierung oder praktische Unterstützung auf eurem Weg mit GitLab-Tokens möchtet, schaut euch unsere GitLab Services an.

DevOps
Eficode ROOT
CI/CD

Subscribe to our newsletter

Related blogs

Keep reading

Blog

Artifactory vs. Nexus vs. ProGet

Artifactory vs. Nexus vs. ProGet: Ein umfassender Vergleich der führenden Artifact Repositories, der euch hilft, das beste Tool für eure DevOps-Pipeline zu finden.

Mastering DevOps with AI: Building next-level CI/CD pipelines

Blog

DevOps mit AI meistern: CI/CD-Pipelines der nächsten Generation entwickeln

In einer sich rasant wandelnden Ära der KI-gestützten Programmierung ist ein solides DevOps entscheidend. Dieser Beitrag zeigt den effizienten Einsatz von KI in CI/CD und betont die Bedeutung menschlicher Expertise.

Blog

AI mit Robot Framework

In diesem Blogbeitrag stellen wir Vorträge von der Konferenz zum Acceptance-Testing-Framework Robot Framework vor, mit einem Schwerpunkt auf künstlicher Intelligenz (KI).

Blog

Ist Apache Groovy oder YAML besser für Pipelines?

Menschen, die Continuous-Delivery-Pipelines schreiben, lassen sich im Allgemeinen in zwei Lager einteilen: das Apache-Groovy- und das YAML-Lager. Welches ist besser?