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

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