OpenBao

Secret-Store und PKI der DEXPRO-Plattform: Einordnung, Nutzung für Anwender, Betrieb für Betreuer.

Schnelleinstieg

Schnelleinstieg

Schnelleinstieg

Zielgruppe: Anwender und Betreuer · Stand: 06.11.2026

OpenBao ist bei DEXPRO der zentrale Ort für Secrets (z. B. Zugänge und Passwörter) und die Zertifizierungsstelle der Plattform. Pipelines melden sich per GitLab-JWT an, VMs per AppRole und Menschen künftig per Entra-Login. Gespeicherte Zugangsdaten braucht dafür niemand.

OpenBao läuft bisher nur im Lab (Lab-PoC). Den aktuellen Stand und die offenen Punkte findest du unter Gültiger Stand und Verlauf.

Als Anwender möchte ich …

Folgt mit DEV. Bis dahin hilft dir zur Orientierung:

Als Betreuer möchte ich …

Weiterführend

Historie und Gültigkeit

Historie und Gültigkeit

Gültiger Stand und Verlauf

Zielgruppe: Anwender und Betreuer · Stand: 06.11.2026

OpenBao ist der Secret-Store und die zentrale Zertifizierungsstelle (CA) der DEXPRO-Plattform. Diese Seite zeigt, was heute gilt, was noch offen ist und wie es dazu kam. Details findest du auf den Seiten der einzelnen Kapitel.

OpenBao läuft bisher nur im Lab (Lab-PoC). Eine DEV- und eine Produktionsumgebung sind geplant, aber noch nicht aufgebaut.

Gültiger Stand

Offen

Verlauf

Weiterführend

Aufbau und Erreichbarkeit

Aufbau und Erreichbarkeit

Cluster, Storage und Seal

Zielgruppe: Betreuer · Stand: 06.11.2026

Das Lab-OpenBao läuft als Cluster aus drei Knoten mit eingebautem Raft-Storage. Es entsiegelt sich nach einem Neustart selbst (Static-Key-Seal). Diese Seite beschreibt Aufbau, Code-Ablage und Seal.

Lab-PoC: Für DEV und Produktion sind Seal-Verfahren und Backup-Konzept noch offen.

Cluster

Code

Repository Inhalt
cloud-core-infrastructure/ansible/roles/openbao Ansible-Rolle (Installation, Konfiguration, Zertifikats-Reload)
cloud-core-infrastructure/terraform-modules/proxmox/openbao Terraform-Modul für die Knoten
cloud-core-infrastructure/bremen1/openbao-servers Stack des Lab-Clusters, nur pre-development

Im VM-Modul haben die Knoten eine eigene Rolle (vault) und keinen Consul-Agent.

Der Stack openbao-servers bezieht seine Zugänge (Proxmox, DNS, NetBox, CheckMK, Seal-Key) aus Bitwarden und nie aus OpenBao. Sonst ließe sich OpenBao nach einem Ausfall nicht wieder aufbauen. Das gilt für jeden späteren Produktions-, Restore- oder Bootstrap-Stack genauso.

Seal

Raft-Daten und Seal-Schlüssel liegen gemeinsam im täglichen Proxmox-Backup. Wer Zugriff auf dieses Backup hat (nur Proxmox-Admins), hat beides. Raft-Snapshots selbst enthalten den Schlüssel nicht.

Weiterführend

Aufbau und Erreichbarkeit

Erreichbarkeit

Zielgruppe: Anwender und Betreuer · Stand: 06.11.2026

OpenBao ist nur im internen Netz erreichbar und nie über den Edge. Wer OpenBao nutzen will, braucht deshalb einen direkten Netzweg zu Port 8200.

Regeln

OpenBao nie über den Edge veröffentlichen, auch nicht vorübergehend. Oberflächen für Menschen laufen über den Edge, interne Dienste und OpenBao nie.

Zugriff für Pipelines

GitLab-Runner brauchen eine Firewall-Freigabe zu den Knoten auf Port 8200, und nur auf diesem Port. Die Freigabe richtet das Netzteam ein. Für die bestehenden Runner ist sie offen.

Prüfen vom Runner aus:

curl -s -o /dev/null -w '%{http_code}\n' https://openbao-lab-bre1.dexpro.parts:8200/v1/sys/health

200 (aktiver Knoten) oder 429 (Standby-Knoten) bedeutet: erreichbar.

Umgekehrt ruft OpenBao die Signaturschlüssel von GitLab (JWKS) ab, um die JWTs der Pipelines zu prüfen. Dieser Weg ist von allen Knoten aus offen.

Weiterführend

Secrets (KV)

Secrets (KV)

Pfadschema und Teamtrennung

Zielgruppe: Anwender und Betreuer · Stand: 06.11.2026

In OpenBao liegen Secrets in KV-Speichern (KV-v2-Mounts). Diese Seite erklärt, wo ein Secret hingehört und wer es lesen und schreiben darf. Wer die Regeln kennt, findet Secrets wieder und legt sie gleich an der richtigen Stelle ab.

Gilt bisher nur im Lab (Lab-PoC). Für DEV und Produktion ist dasselbe Schema vorgesehen.

Ein Mount je Abteilung

Jede Abteilung hat einen eigenen Mount:

Mount Abteilung
cci/ Cloud Core Infrastructure (CCI)
cpi/ Container Platform Infrastructure (CPI)
cpcs/ Container Platform Core Services (CPCS)
cpds/ Container Platform DEXPRO Services (CPDS)

Pfade

Standardschema für alle Abteilungen außer CCI:

Pfad Wofür
<abt>/<team>/<stage>/… Secrets eines Teams
<abt>/shared/<stage>/… Secrets der ganzen Abteilung (shared ist als Teamname reserviert)
<abt>/<team>/<stage>/nomad/<job>/… Secrets eines Nomad-Jobs

CCI ist ein Team und gliedert sich deshalb nach Standort und Projekt:

Pfad Wofür
cci/shared/<stage>/… für die ganze Abteilung, z. B. zentrale DNS- oder IPAM-Zugänge
cci/<standort>/<stage>/shared/… für alle Projekte eines Standorts, z. B. bremen1
cci/<standort>/<stage>/<projekt>/… nur für dieses Projekt

<stage> ist immer der Branch-Name: pre-development, development, staging oder production. Das Lab nutzt pre-development.

Woher Stage und Team kommen

Metadaten an einem Secret (custom_metadata) sind nur eine Beschriftung. Sie schützen nichts. Zugriff regeln allein Pfad und Policy.

Wer darf was

Lesen Schreiben Endgültig löschen
Team-Pipeline eigener Teampfad und shared/ der Abteilung eigener Teampfad (production nur von geschützten Branches) nein (nur Soft-Delete)
Mensch im Team eigener Teampfad und shared/ eigener Teampfad und shared/ ja
Nomad-Job nur …/nomad/<job>/ nein (Anlegen und Rotieren macht die Team-Pipeline) nein
Globale OpenBao-Admins alle KV-Mounts alle KV-Mounts ja

Ausnahme CCI: Hier dürfen auch Pipelines in beide shared-Ebenen schreiben (Soft-Delete ja, endgültig löschen nein). Ein Projekt schreibt nur in seinen eigenen Projektpfad.

Die globalen Admins sind eine eigene Entra-Gruppe. Sie dürfen Secrets verwalten, aber OpenBao nicht konfigurieren (keine Policies, Anmeldeverfahren oder Mounts). Die Konfiguration entsteht als Code.

Wer Policies oder Anmeldeverfahren schreiben darf, kann sich selbst jedes Recht geben. Diese Rechte gibt es deshalb nur für die Konfiguration als Code und das Admin-Token, nie für Teams.

Weiterführend

Secrets (KV)

Secret anlegen

Zielgruppe: Betreuer · Stand: 06.11.2026

Secrets entstehen auf genau zwei Wegen: Menschen legen sie nach dem Login per OIDC in der OpenBao-Oberfläche an, Pipelines schreiben sie mit ihrem GitLab-JWT. Andere Wege wie Admin-Token oder lokale Skripte sind nicht vorgesehen. Eine Anleitung für Anwender folgt, sobald es OpenBao in DEV gibt.

Lab-PoC: Der OIDC-Login (Entra ID) kommt erst mit DEV. Bis dahin entstehen Secrets im Lab nur über Pipelines.

Voraussetzungen

Vorgehen: Oberfläche (OIDC)

  1. OpenBao-Oberfläche öffnen und als Methode OIDC wählen, dann mit dem DEXPRO-Konto anmelden.
  2. Den Mount deiner Abteilung öffnen, z. B. cpds/.
  3. Create secret wählen und als Pfad den Pfad ohne Mount eintragen, z. B. <team>/<stage>/<name>.
  4. Schlüssel und Werte eintragen und speichern.

Vorgehen: Pipeline (GitLab-JWT)

  1. Die CI-Component meldet die Pipeline per GitLab-JWT an OpenBao an und stellt das Token als BAO_TOKEN bereit. Module und Jobs melden sich nicht selbst an.
  2. Terraform schreibt das Secret mit dem Vault-Provider (Ressource vault_kv_secret_v2) in den eigenen Pfad, z. B. ein von random_password erzeugtes Passwort.
  3. Die Pipeline darf nur in ihren eigenen Pfad schreiben (bei CCI auch in die shared-Ebenen), production nur von geschützten Branches.

Prüfen

In der Oberfläche zeigt das Secret unter Version History die neue Version mit Zeitstempel. In der Pipeline zeigt der Terraform-Plan bzw. das Apply die Ressource, aber nie den Wert.

Erscheint die neue Version mit dem erwarteten Zeitpunkt, ist das Secret angelegt.

Stolperfallen

Die Stage im Pfad muss exakt der Branch-Name sein (pre-development, nicht lab oder dev). Sonst findet die Pipeline das Secret nicht.

Weiterführend

Secrets (KV)

Secret-Versionen und Löschen

Zielgruppe: Betreuer · Stand: 06.11.2026

OpenBao hebt je Secret mehrere Versionen auf, und Löschen geht in zwei Stufen. Hier steht, wie du eine alte Version zurückholst und wann ein Secret wirklich weg ist. Menschen arbeiten dafür nach dem OIDC-Login in der Oberfläche, Pipelines über Terraform.

Regeln

Vorgehen (Oberfläche)

  1. Nach dem OIDC-Login das Secret öffnen und Version History wählen.
  2. Ältere Version zurückholen: die Version öffnen und daraus eine neue Version erstellen. Der alte Inhalt wird damit zur aktuellen Version.
  3. Soft-Delete / Wiederherstellen: bei der Version „Delete“ bzw. „Undelete“ wählen.

Endgültig und nicht umkehrbar: „Destroy“ löscht die Daten einer Version, das Löschen der Metadaten entfernt das Secret mit allen Versionen. Vorher prüfen, dass keine Pipeline und kein Dienst das Secret noch nutzt.

Pipelines

Pipelines dürfen laut Policy nur soft-löschen. Endgültig löschen kann nur ein Mensch in der Oberfläche.

Prüfen

In Version History sind soft-gelöschte Versionen als gelöscht markiert, zerstörte als „destroyed“.

Stolperfallen

Weiterführend

Anmeldung

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

Anmeldung

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

Anmeldung

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

Anmeldung

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

PKI

PKI

Offline-Root-CA und Intermediates

Zielgruppe: Betreuer · Stand: 06.11.2026

OpenBao ist die zentrale Zertifizierungsstelle (CA) der Plattform. Die Root-CA bleibt offline. In OpenBao arbeiten nur Intermediate-CAs, und zwar eine je Zweck. Diese Seite erklärt den Aufbau und warum er so gewählt ist.

Lab-PoC: Bisher gibt es die Root-CA des Labs und ein Intermediate für Consul.

Aufbau

Ebene Wo Laufzeit Eigenschaften
Root-CA offline, nie auf einer VM, nie im Terraform-State, nie in OpenBao 10 Jahre ECDSA P-384, darf nur eine Ebene Intermediates signieren
Intermediate je Zweck eigener PKI-Mount in OpenBao, z. B. pki-consul 3–5 Jahre Schlüssel verlässt OpenBao nie, Namen per Name Constraints begrenzt
Zertifikate (Leaf) auf den Hosts kurz, z. B. Consul 30 Tage werden automatisch erneuert

Geplante weitere Intermediates: Nomad-TLS und Consul-Connect.

Wie ein Intermediate entsteht

  1. OpenBao erzeugt im neuen PKI-Mount Schlüssel und CSR. Der Schlüssel bleibt in OpenBao.
  2. Die Root-CA signiert die CSR offline auf einem abgeschotteten Rechner, in einem Speicher, der beim Ausschalten verschwindet.
  3. Das signierte Zertifikat wird in OpenBao importiert.
  4. Rollen im Mount legen fest, welche Namen und IPs Zertifikate bekommen dürfen.

Der Root-Schlüssel ist verschlüsselt in Bitwarden gesichert und wird nur zum Signieren kurz geladen.

Öffentliche CA-Daten

CA-Zertifikat, Kette und Sperrliste eines Mounts sind ohne Token abrufbar, z. B. für Clients, die der CA vertrauen sollen:

curl -s https://openbao-lab-bre1.dexpro.parts:8200/v1/pki-consul/ca_chain

Stolperfallen

IP-Adressen in Rollen begrenzt nur das Feld allowed_ip_sans_cidr. Ein Feld allowed_ip_sans wird still ignoriert, und allow_ip_sans=true allein erlaubt beliebige IPs. Nach jeder Rollenänderung mit einer unerlaubten IP gegenprüfen (Erwartung: HTTP 400).

Weiterführend

PKI

Consul-Zertifikate aus OpenBao

Zielgruppe: Betreuer · Stand: 06.11.2026

Die Lab-Consul-Server holen ihre TLS-Zertifikate aus OpenBao und erneuern sie selbst. Die Consul-Clients bekommen ihre Zertifikate von den Servern. Diese Seite beschreibt den Ablauf. Das spätere Consul-Buch verlinkt hierher.

Lab-PoC: Die Lab-Consul-Server sind auf diesem Weg neu aufgebaut. Die ACL-Einrichtung ist noch nicht abgeschlossen, weil sie an der abgebauten Lab-Nomad-Anmeldung hängt.

Ablauf

  1. Das Terraform-Modul proxmox/consul legt je Server eine an die Host-IP gebundene AppRole-Secret-ID an (siehe VMs per AppRole anmelden).
  2. Die Ansible-Rolle consul installiert bao und richtet den bao agent ein.
  3. Der Agent holt aus dem Mount pki-consul Zertifikat und Schlüssel (Server-Zertifikat für server.<dc>.consul und den FQDN des Hosts, Laufzeit 90 Tage) und lädt Consul bei jeder Erneuerung neu.
  4. Clients holen ihre Zertifikate per auto_encrypt vom Server und brauchen nur die CA-Kette. Die Kette liest das Modul ohne Token aus OpenBao.
  5. Gossip-Key und ACL-Bootstrap-Token spiegelt das Modul zusätzlich nach OpenBao (KV-Mount consul/). Im Lab bleibt Bitwarden dafür führend, in DEV soll OpenBao allein die Quelle sein.

Versionen

Prüfen

Der bao agent schreibt nach jedem Rendern eine Statusdatei unter /etc/consul.d/openbao/. Consul antwortet auf Port 8501 mit einem Zertifikat aus pki-consul.

Stolperfallen

Für Zertifikat, Schlüssel und CA nur eine template-Stanza mit pkiCert verwenden. Drei Stanzas stellen drei verschiedene Zertifikate aus, und Schlüssel und Zertifikat passen nicht zusammen.

Weiterführend

Betrieb

Betrieb

Snapshot und Restore

Zielgruppe: Betreuer · Stand: 06.11.2026

Ein Raft-Snapshot sichert alle Daten von OpenBao: Secrets, Konfiguration und PKI. Im Lab ist belegt, dass sich ein Snapshot in eine leere Instanz zurückspielen lässt.

Lab-PoC: Im Lab gibt es keine automatischen Snapshots, nur das tägliche Proxmox-Backup der VMs. Für Produktion sind automatische Snapshots außerhalb der Knoten Pflicht.

Voraussetzungen

Vorgehen

  1. Snapshot erstellen:

    bao operator raft snapshot save <datei>

  2. Snapshot sicher ablegen. Er enthält alle Secrets, verschlüsselt mit dem Seal.

  3. Restore in eine Instanz:

    bao operator raft snapshot restore <datei>
    • <datei>: Pfad zur Snapshot-Datei

Ein Restore überschreibt alle Daten der Zielinstanz. Vorher von der Zielinstanz selbst einen Snapshot ziehen.

Prüfen

Nach dem Restore zeigt bao operator raft list-peers alle Knoten, und ein bekanntes Secret ist mit der erwarteten Version lesbar.

Stolperfallen

Weiterführend

Betrieb

Konfiguration als Code

Zielgruppe: Betreuer · Stand: 06.11.2026

Die Konfiguration von OpenBao (Mounts, Policies, Anmeldeverfahren und Rollen) entsteht als Code, nicht von Hand in der Oberfläche. Heute erledigen das Skripte, später Terraform aus einer Teamliste.

Was konfiguriert wird

Regeln

Zielbild

Eine Teamliste ist die einzige Quelle. Aus ihr erzeugt Terraform mit dem Vault-Provider Policies, JWT-Rollen, Entra-Gruppenzuordnungen und später auch Nomad-Bindungen. Die Namen leiten sich nach einem festen Muster ab, z. B. Policy <abt>-<team> und JWT-Rolle <abt>-<team>-ci. Für CCI gilt das Muster je Standort und Projekt.

Die Skripte und die spätere Terraform-Konfiguration kommen in ein Repository. Diese Seite verlinkt sie, sobald sie dort liegen.

Weiterführend

Betrieb

Listener-Zertifikat

Zielgruppe: Betreuer · Stand: 06.11.2026

Der Listener von OpenBao nutzt das Wildcard-Zertifikat *.dexpro.parts. Jeder Knoten holt es selbst und lädt OpenBao neu, sobald ein neues Zertifikat da ist. Der Reload ist allerdings noch nie im Ernstfall gelaufen.

Das aktuelle Zertifikat gilt bis 04.12.2026. Bis dahin müssen Reload-Test und Überwachung erledigt sein.

Wie es funktioniert

  1. Das Modul bindet certmanager ein. Jeder Knoten holt das Zertifikat vom SSL-Service nach /var/certmanager/certs/.
  2. Ein Timer prüft täglich um 03:00 Uhr. Gilt das Zertifikat weniger als 7 Tage, wird es ersetzt.
  3. Eine systemd-Path-Unit (openbao-cert-reload.path) bemerkt die Änderung und lädt OpenBao neu (systemctl reload openbao).

Prüfen

echo | openssl s_client -connect openbao-lab-bre1.dexpro.parts:8200 2>/dev/null | openssl x509 -noout -enddate

Das Ablaufdatum muss auf allen drei Knoten gleich sein und nach dem Erneuern weiter in der Zukunft liegen.

Stolperfallen

Weiterführend