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 - Das Repo nutzt die CI-Component `cloud-core-infrastructure/ci-components/deployment`. - In OpenBao gibt es eine JWT-Rolle für das Projekt. Sie ist an Projekt, Branch und geschützten Branch gebunden. - Der Branch ist geschützt. Alle vier Stage-Branches sollten es ohnehin sein. - Der Runner erreicht OpenBao direkt auf Port 8200. ## Vorgehen 1. Inputs im `include` setzen: ```yaml include: - component: $CI_SERVER_FQDN/cloud-core-infrastructure/ci-components/deployment/terraform@Der Job meldet den erfolgreichen Login, und plan liest die erwarteten Secrets. Ein Zugriff auf fremde Pfade oder eine andere Stage endet mit 403.
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 - Je Dienst gibt es **eine** AppRole, z. B. eine für alle Consul-Server. - Für jeden Host erzeugt der Terraform-Lauf eine eigene Secret-ID. Sie ist an die Host-IP gebunden und entsteht im selben Lauf, nachdem die IP feststeht und bevor Ansible läuft. - Die Secret-ID landet nie im Terraform-State. Sie geht über eine temporäre Datei des Runners direkt auf den Host. - Auf dem Host liegt sie dauerhaft (nur root lesbar), damit sich der `bao agent` nach einem Neustart wieder anmelden kann. Bei Consul ist das `/etc/consul.d/openbao/secret-id`. - Der `bao agent` holt damit die Zertifikate und lädt den Dienst bei Erneuerung neu. ## 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üfenDie 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.
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.
- Bei einem Neuaufbau mit neuer IP braucht der Host eine neue Secret-ID. Die Pipeline erzeugt sie im selben Lauf. ## Weiterführend - [Consul-Zertifikate aus OpenBao](https://docs.squeeze.one/books/openbao/page/consul-zertifikate-aus-openbao) - [OpenBao: AppRole](https://openbao.org/docs/auth/approle/) # Menschen-LoginZielgruppe: 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) - Login in der OpenBao-Oberfläche über **OIDC** mit dem DEXPRO-Konto. - Das Team ergibt sich aus der Entra-Gruppe. Danach richten sich die Rechte (siehe [Pfadschema und Teamtrennung](https://docs.squeeze.one/books/openbao/page/pfadschema-und-teamtrennung)). - Auf diesem Weg legen Menschen Secrets an. ## Lab (heute)Lab-PoC: Es gibt kein OIDC. Die Administration läuft über ein Admin-Token. Secrets entstehen im Lab nur über Pipelines.
- Das Admin-Token ist für die Konfiguration gedacht, nicht für den Alltag. - Es wird nur bei Bedarf eingesetzt und nie gespeichert oder ausgegeben. ## Weiterführend - [Admin-, Break-glass- und Root-Token](https://docs.squeeze.one/books/openbao/page/admin-break-glass-und-root-token) - [Secret anlegen](https://docs.squeeze.one/books/openbao/page/secret-anlegen) # Admin-, Break-glass- und Root-TokenZielgruppe: 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. ## StolperfallenDie 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.