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 
 
 Drei VMs ob-001-bre1-01..03.dexpro.parts mit je 2 CPU und 4 GB RAM, Storage per Raft. 
 Cluster-Adresse openbao-lab-bre1.dexpro.parts:8200 , ein DNS-Name mit A-Records auf alle drei Knoten. 
 Das Listener-Zertifikat ist das Wildcard-Zertifikat *.dexpro.parts (siehe Listener-Zertifikat ). 
 Die Knoten finden sich über ihre DNS-Namen, nie über *.service.consul . 
 Die Knoten sind nicht in Consul registriert, weil Consul seine Zertifikate aus OpenBao bekommt. Monitoring läuft über CheckMK. 
 Ein Knoten darf ausfallen, ohne dass Lesen und Ausstellen stoppen. Das ist im Lab getestet. 
 
 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 
 
 Static-Key-Seal: Ein Schlüssel auf jedem Knoten unter /etc/openbao/seal/ (nur root/openbao lesbar, außerhalb der Raft-Daten). Nach einem Neustart entsiegelt sich der Knoten damit selbst. 
 Recovery-Keys: fünf Anteile, drei davon genügen. Gesichert in Bitwarden. 
 
 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 
 
 Erreichbarkeit 
 Snapshot und Restore 
 OpenBao: Integrated Storage (Raft) 
 OpenBao: Seal/Unseal

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 
 
 Erreichbar ist nur der interne Listener auf Port 8200 , über openbao-lab-bre1.dexpro.parts:8200 . 
 Port 8201 nutzen nur die Knoten untereinander. Er wird nie freigegeben. 
 Der Edge leitet nichts zu OpenBao. Das ist im Lab per Negativtest belegt. 
 Ohne Token liefert OpenBao nur die öffentlichen CA-Daten (CA-Zertifikat, Kette, Sperrliste). 
 
 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 
 
 Pipeline per GitLab-JWT anmelden 
 OpenBao: sys/health