Token-Erneuerung einrichten

Zielgruppe: Betreuer · Stand: 09.11.2026

Admin-Token und Reserve-Token (Break-glass) von OpenBao sind periodische Token und laufen ab, wenn niemand sie erneuert. Eine Pipeline im Projekt cloud-core-infrastructure/openbao-maintenance übernimmt das regelmäßig. Diese Seite zeigt, wie du sie für einen OpenBao-Cluster einrichtest, ob zum ersten Mal oder für einen weiteren Cluster. Wie die Token aufgebaut sind, steht unter Admin-, Break-glass- und Root-Token.

Die Pipeline verlängert die Token nur. Sie legt keine neuen an. Das Admin-Token und das Reserve-Token müssen also schon existieren.

Voraussetzungen

• Du hast ein Admin-Token für den Cluster und bao ist eingerichtet (Adresse und Token per Umgebung, nicht in Dateien).
• Die Anmeldung per GitLab-JWT ist am Cluster aktiv (siehe Pipeline per GitLab-JWT anmelden). Im Folgenden heißt der Mount jwt-gitlab.
• Das Pipeline-Projekt cloud-core-infrastructure/openbao-maintenance gibt es und main ist ein geschützter Branch. Du brauchst seine numerische Projekt-ID (Projekteinstellungen).
• Platzhalter in den Beispielen:
  • <openbao-adresse>: Adresse des Clusters mit Port, zugleich Audience des JWT, z. B. https://openbao.example.dexpro.parts:8200
  • <projekt-id>: numerische ID des Pipeline-Projekts

Vorgehen

1. Obergrenze der Token-Laufzeit prüfen. Die Periode der Token ist 90 Tage. Der Token-Mount muss das erlauben, sonst kappt OpenBao die Laufzeit still.

   bao read sys/auth/token/tune
   bao auth tune -max-lease-ttl=2160h token/
   

   Der zweite Befehl ist nur nötig, wenn max_lease_ttl unter 2160h liegt.

2. Policy anlegen. Sie erlaubt nur, Token per Accessor nachzuschlagen und zu erneuern. Lesen oder Nutzen der Token ist damit nicht möglich.

   path "auth/token/lookup-accessor" { capabilities = ["update"] }
   path "auth/token/renew-accessor"  { capabilities = ["update"] }
   

   bao policy write token-renew token-renew.hcl
   

3. JWT-Rolle anlegen. Sie bindet die Anmeldung an genau dieses Projekt, den geschützten Branch main und die Auslöser Zeitplan oder manuell.

   {
     "role_type": "jwt",
     "user_claim": "project_path",
     "bound_audiences": ["<openbao-adresse>"],
     "bound_claims": {
       "project_id": "<projekt-id>",
       "ref": "main",
       "ref_protected": "true",
       "pipeline_source": ["schedule", "web"]
     },
     "token_policies": ["token-renew"],
     "token_ttl": 300,
     "token_max_ttl": 600,
     "token_no_default_policy": true
   }
   

   bao write auth/jwt-gitlab/role/token-renew @role.json
   

4. Accessoren der beiden Token ermitteln. Der Accessor ist eine Kennung, mit der sich das Token nicht benutzen lässt. Mit dem jeweiligen Token in der Umgebung:

   bao token lookup -format=json | jq -r '.data.accessor'
   

   Ausgegeben wird nur der Accessor, nie das Token.

5. CI-Variablen im Pipeline-Projekt setzen (Einstellungen → CI/CD → Variablen). Alle Variablen mit Accessoren sind maskiert und geschützt.

   Variable	Inhalt
   OPENBAO_ADDR	<openbao-adresse>
   OPENBAO_JWT_ROLE	token-renew
   OPENBAO_ACCESSOR_ADMIN	Accessor des Admin-Tokens
   OPENBAO_ACCESSOR_RESERVE	Accessor des Reserve-Tokens

   Die zwei Accessoren stehen in getrennten Variablen, weil GitLab keine Werte mit Komma maskiert. Die Pipeline fügt sie selbst zusammen.

6. Zeitpläne anlegen (Build → Pipeline-Zeitpläne), Branch main. Ein Hauptlauf etwa alle zwei Monate und ein zweiter Lauf zwei Wochen versetzt als Netz:

   Zeitplan	Cron
   Hauptlauf	0 5 1 */2 *
   Netz-Lauf	0 5 15 */2 *

7. Erstlauf starten. Den Hauptlauf-Zeitplan manuell auslösen.

Prüfen

Der Job ist grün und das Log zeigt für jedes Token OK Eintrag … Laufzeit 90 Tage. Das Ablaufdatum der Token liegt danach etwa 90 Tage in der Zukunft.

bao token lookup -format=json | jq -r '.data.expire_time'

Stolperfallen

Ändert sich der Accessor eines Token, schlägt der Lauf fehl, denn der alte Accessor gilt nicht mehr. Das passiert, wenn ein Token neu ausgestellt wird. Dann musst du die zugehörige Variable anpassen.

• Die Rolle ist an Projekt und Branch gebunden. Läuft der Job auf einem anderen Branch, ist die Anmeldung abgelehnt. Das gilt auch für Läufe aus Merge-Requests.
• Meldet der Job „Laufzeit nur … Tage“, kappt der Token-Mount die Periode. Hebe max_lease_ttl an (Schritt 1).
• Schlägt ein Lauf fehl, benachrichtigt GitLab den Besitzer des Zeitplans. Die Token halten 90 Tage, bis zum Netz-Lauf bleibt also Zeit.
• Neue Token entstehen nicht in der Pipeline. Wer ein Reserve-Token verliert, erzeugt es über den Notweg und legt danach die Accessor-Variable neu an.

Weiterführend

• Admin-, Break-glass- und Root-Token
• Pipeline per GitLab-JWT anmelden
• Projekt openbao-maintenance
• OpenBao: Token auth