Anmeldung

Pipeline per GitLab-JWT anmelden

Zielgruppe: Betreuer · Stand: 06.11.2026

Pipelines melden sich mit ihrem GitLab-JWT bei OpenBao an. Sie brauchen dafür kein gespeichertes Token. Den Login übernimmt die CI-Component ci-components/deployment. Das Deployment-Repo setzt nur zwei Inputs. Eine Anleitung für Anwender folgt mit DEV.

Lab-PoC: Bisher gibt es nur das Lab-OpenBao. Die JWT-Rollen legen Betreuer an.

Voraussetzungen

Vorgehen

  1. Inputs im include setzen:

    include:
  - component: $CI_SERVER_FQDN/cloud-core-infrastructure/ci-components/deployment/terraform@<version>
    inputs:
      openbao-jwt-role: <rolle>
      openbao-addr: https://openbao-lab-bre1.dexpro.parts:8200
    • <version>: Version bzw. SHA der Component, auf die das Repo pinnt
    • <rolle>: JWT-Rolle des Projekts in OpenBao

  2. Im Terraform-Code den Vault-Provider ohne Zugangsdaten konfigurieren. Er liest Adresse und Token aus der Umgebung:

    provider "vault" {}

  3. Pipeline auf dem Stage-Branch starten.

Was dann passiert: Die Jobs plan, deploy und destroy holen sich vor tofu das JWT, prüfen die Erreichbarkeit von OpenBao und tauschen das JWT gegen ein kurzlebiges Token (15 Minuten, höchstens 1 Stunde). Es steht nur in der Shell des Jobs als BAO_TOKEN/BAO_ADDR und VAULT_TOKEN/VAULT_ADDR bereit und wird nie ausgegeben.

Prüfen

Der Job meldet den erfolgreichen Login, und plan liest die erwarteten Secrets. Ein Zugriff auf fremde Pfade oder eine andere Stage endet mit 403.

Stolperfallen

Weiterführend

VMs per AppRole anmelden

Zielgruppe: Betreuer · Stand: 06.11.2026

VMs, die selbst Zertifikate oder Secrets aus OpenBao holen (heute die Lab-Consul-Server), melden sich per AppRole an. Ihre Secret-ID gilt nur von der IP-Adresse des jeweiligen Hosts aus.

Lab-PoC: Bisher nutzen nur die Lab-Consul-Server diesen Weg.

Wie es funktioniert

Vorgehen

Die Anmeldung richten Modul und Rolle ein, es gibt keine Handarbeit. Für einen neuen Dienst:

  1. Im Modul die AppRole-Anbindung nach dem Muster des Consul-Moduls übernehmen.
  2. Die AppRole und ihre Policies als Konfiguration in OpenBao anlegen.
  3. Deploy über die Pipeline. Die Pipeline braucht dafür eine JWT-Rolle, die Secret-IDs erzeugen darf.

Prüfen

Die Rolle bricht im Preflight ab, wenn die Secret-ID-Datei fehlt. Läuft sie durch und hat der bao agent die Zertifikate geschrieben, funktioniert die Anmeldung.

Stolperfallen

Die IP-Bindung prüft die Adresse, die OpenBao sieht. Hinter NAT (z. B. WSL) ist das eine andere als die Host-IP, und der Login scheitert.

Weiterführend

Menschen-Login

Zielgruppe: Betreuer · Stand: 06.11.2026

Menschen melden sich in DEV künftig per OIDC mit ihrem DEXPRO-Konto (Entra ID) an. Im Lab gibt es das noch nicht. Dort administrieren Betreuer OpenBao mit dem Lab-Admin-Token.

DEV und Produktion (geplant)

Lab (heute)

Lab-PoC: Es gibt kein OIDC. Die Administration läuft über ein Admin-Token. Secrets entstehen im Lab nur über Pipelines.

Weiterführend

Admin-, Break-glass- und Root-Token

Zielgruppe: Betreuer · Stand: 06.11.2026

Ohne Root-Token braucht OpenBao zwei Notfall-Zugänge: ein Admin-Token für die Administration und ein Reserve-Token (Break-glass) für den Fall, dass das Admin-Token verloren geht. Diese Seite erklärt, wozu die beiden da sind und was bei ihrer Pflege wichtig ist.

Ohne gültiges Admin- oder Reserve-Token gibt es nach dem Widerruf des Root-Tokens keinen normalen Rückweg mehr. Im schlimmsten Fall muss OpenBao neu aufgebaut werden. Beide Token müssen deshalb immer gültig sein.

Die drei Token

Token Zweck Rechte
Root-Token nur bei der Erstinstallation alles; im Lab nach der Einrichtung widerrufen
Admin-Token Administration und Konfiguration Administration, ohne Zugriff auf Raw-Daten und ohne Versiegeln
Reserve-Token (Break-glass) Notfall: neues Root-Token erzeugen nur das Erzeugen eines Root-Tokens und die Pflege des eigenen Tokens

Admin- und Reserve-Token sind periodische Token ohne Elterntoken mit 90 Tagen Periode. Sie laufen nur dann nicht ab, wenn sie rechtzeitig erneuert werden.

Pflege

  1. Beide Token spätestens alle 90 Tage erneuern, empfohlen alle 60 Tage. Eine Prüfung warnt unter 30 Tagen Restlaufzeit.
  2. Token nur bei Bedarf und nur verdeckt einsetzen, nie in Dateien, Logs oder Tickets schreiben.

Stolperfallen

Die Obergrenze für Token-Laufzeiten am Token-Mount (max_lease_ttl) kappt die Periode still. Mit dem Standardwert läuft ein „90-Tage“-Token nach etwa 32 Tagen ab. Die Obergrenze ist deshalb auf 90 Tage angehoben. Nebenwirkung: Auch andere Token aus diesem Mount dürfen bis 90 Tage laufen.

Weiterführend