OpenBao: Open-Source-Tresor für Zugangsdaten und Zertifikate

Vom Vault-Fork zur Stiftungslösung

Der Ursprung des Projekts geht auf eine Lizenzentscheidung zurück. Im August 2023 stellte HashiCorp seine Produkte auf die Business Source License 1.1 (BSL) um. Die Lizenz untersagt den kommerziellen Wettbewerb mit dem Hersteller und gilt nicht mehr als quelloffen im Sinne der Open Source Initiative. Aufgrund restriktiver Bedingungen der BSL – insbesondere der Klausel für Non-Governmental Entities –, welche den freien kommerziellen Wettbewerb einschränkt, sahen sich viele Teilnehmer der Linux Foundation gezwungen, Lösungen ohne diese Lizenzbindung auf Basis des bisherigen Open Source-Codium zu entwickeln. Dies ebnete den Weg für Initiativen wie OpenBao. Aus dieser Lage heraus startete ein Fork des letzten quelloffenen Vault-Standes aus dem Zweig 1.14.x unter der Mozilla Public License 2.0.

Für Unternehmen entsteht dadurch mehr Planbarkeit bei Lizenz, Governance und Weiterentwicklung. Die Lizenz bleibt zuverlässig, ein nachträglicher Wechsel auf ein kommerzielles Modell droht nicht. Jede Funktion steht allen Anwendern offen, eine Aufteilung in eine gratis Basis und kostenpflichtige Zusatzmodule gibt es in diesem Fork nicht. SAP setzt OpenBao zum Beispiel im Rahmen seiner EU-geförderten Initiative ApeiroRA als Verwaltung für Secrets und Schlüssel ein und steuert Beiträge zum Code bei.

Geheimnisverwaltung für maschinelle Zugriffe

Im Zentrum der Lösung stehen maschinelle Zugriffe. Anwendungen, Dienste, Container und Pipelines benötigen Zugangsdaten zu Datenbanken, APIs und Cloud-Plattformen. Klassische Passwort-Manager sind vor allem für menschliche Nutzerkonten gedacht. OpenBao konzentriert sich auf die Geheimnisse von Systemen und Anwendungen. Daraus ergeben sich hohe Anforderungen an Verfügbarkeit, Automatisierbarkeit und Integrierbarkeit.

Die Zahl maschineller Identitäten wächst schneller als die der menschlichen Konten. Jede dieser Identitäten benötigt ein Geheimnis, das gespeichert, rotiert und bei Bedarf zurückgezogen werden muss. Ohne zentrale Verwaltung verteilen sich Zugangsdaten unkontrolliert. Ohne zentrale Verwaltung bleiben Datenbankpasswörter oft lange unverändert, mehrere Dienste nutzen denselben Schlüssel, und Rotationen scheitern an fehlender Transparenz.

Ein fehlender Audit-Trail verhindert die Nachvollziehbarkeit von Zugriffen. OpenBao begegnet diesem Muster mit verschlüsselter Ablage, einem einheitlichen API-Zugang und einem vollständigen Protokoll über Lese-, Schreib- und Rotationsvorgänge.

Secret Engines und dynamische Zugangsdaten

OpenBao gliedert seine Funktionen in Secret Engines, die jeweils einen Typ sensibler Daten verwalten. Die Key-Value-Engine in Version 2 legt statische Geheimnisse als Schlüssel-Wert-Paare (Key Value Pair) hinter der kryptografischen Barriere ab. Anwendungen rufen Passwörter und Token über das API ab, statt sie in Code oder Konfiguration zu hinterlegen.

Dynamische Geheimnisse erweitern dieses Prinzip. OpenBao erzeugt Zugangsdaten erst im Moment der Anfrage und versieht sie mit einer Gültigkeitsdauer. Nach Ablauf des Lease zieht das System die Anmeldedaten automatisch zurück. Solche kurzlebigen Zugänge lassen sich für SQL- und NoSQL-Datenbanken, Kubernetes, AWS-IAM-Konten, SSH-Schlüssel und Active-Directory-Konten generieren. Ein versehentlich geleaktes Geheimnis verliert dadurch nach kurzer Zeit seine Wirkung.

Für die Lebenszyklus-Steuerung sorgt ein Mechanismus aus Lease, Renew und Revoke. Clients verlängern die Gültigkeit über eine integrierte Schnittstelle. Der Widerruf greift einzeln oder über einen ganzen Baum, der alle von einem Nutzer gelesenen Geheimnisse oder alle Einträge eines bestimmten Typs umfasst. Eine eigene PKI-Engine stellt X.509-Zertifikate aus und übernimmt deren Verwaltung. Die Transit-Engine stellt Verschlüsselung als Dienst bereit. Anwendungen lassen Daten von OpenBao ver- und entschlüsseln, ohne selbst Schlüsselmaterial zu halten. Die verschlüsselten Daten bleiben im jeweiligen Datenspeicher, die zentrale Schlüsselverwaltung liegt bei OpenBao.

Identitätsbasierter Zugriff und Protokollierung

OpenBao arbeitet identitätsbasiert. Vor jedem Zugriff prüft das System die Identität des Clients und gleicht sie gegen hinterlegte Richtlinien ab. Erst nach erfolgreicher Authentifizierung und Autorisierung gibt OpenBao ein Geheimnis frei.

Verschiedene Cloud-Plattformen und Dienste bringen eigene Identitätskonzepte mit. OpenBao bündelt verschiedene Authentifizierungsverfahren über Richtlinien und verknüpft Identitäten aus unterschiedlichen Systemen über ein einheitliches Zugriffsmodell. Unterstützt werden unter anderem Token, Kubernetes, JWT/OIDC und AppRole. Organisationen regeln den Zugriff über zentrale Richtlinien, statt jede Plattform getrennt zu konfigurieren.

Jeder Zugriff hinterlässt eine Spur. Audit Devices protokollieren, welcher Client ein Geheimnis liest, schreibt oder rotiert. Für Umgebungen mit Compliance-Anforderungen liefert dieses Protokoll die nötige Nachweisbarkeit. Ein zusätzliches Webhook-basiertes Audit Device kann die Protokollierung an externe Systeme weitergeben.

Architektur, Storage und Auto-Unseal

OpenBao lässt hochverfügbar über mehrere Knoten betreiben. Als Plattform dienen virtuelle Maschinen oder Kubernetes. Für die persistente Ablage stehen verschiedene Speicher-Backends zur Verfügung. Das integrierte Raft-Backend bringt eine eigene replizierte Speicherung mit; PostgreSQL ist eine mögliche Alternative, vor allem bei einem bereits vorhandenen hochverfügbaren Cluster und erfahrener Datenbankadministration.

Nach dem Start befindet sich OpenBao in einem versiegelten Zustand und kann seinen eigenen Speicher nicht entschlüsseln. Erst das Entsiegeln gibt den Zugriff frei. Dahinter steht ein Schlüssel, der den Hauptschlüssel schützt. Beim manuellen Verfahren führen mehrere Schlüsselhalter ihre Teile zusammen, bis eine definierte Schwelle erreicht ist.

Für den Produktivbetrieb empfiehlt sich das automatische Entsiegeln. Ein Schlüsselverwaltungsdienst übernimmt die Aufgabe und hält die Verfügbarkeit auch dann aufrecht, wenn ein Cluster nachts ausfällt. Als Quelle dienen die Key-Management-Dienste der Hyperscaler von AWS, Azure, Google Cloud und weiteren Anbietern oder ein Hardware-Sicherheitsmodul über das Protokoll PKCS#11. Ein HSM bietet sich für regulierte Umgebungen und für Organisationen an, die externe Abhängigkeiten reduzieren und die Datenhoheit behalten. Das HSM von Securosys gilt als erstes offiziell verifiziertes Modul für OpenBao.

Mit Namespaces grenzt OpenBao Mandanten voneinander ab und ermöglicht eine Mehrmandantenfähigkeit, die in der quelloffenen Version vollständig enthalten ist. Bei HashiCorp Vault bleibt diese Funktion der kostenpflichtigen Enterprise-Variante vorbehalten. Seit der Version 2.5 verteilen Standby-Knoten Lesezugriffe lokal, statt jede Anfrage an den aktiven Knoten weiterzuleiten. Schreibvorgänge gehen weiterhin an den führenden Knoten, das Ergebnis steht erst mit kurzer Verzögerung auf allen Knoten bereit. Die Lesezugriffe skalieren dadurch horizontal, leselastige Umgebungen profitieren davon am stärksten.

Inbetriebnahme mit Docker und CLI

Für den Einstieg liefert OpenBao vorgefertigte Container-Images auf Basis von Alpine Linux und RHEL UBI. Die Images liegen in den Registries ghcr.io, quay.io und docker.io. Ein Entwicklungsmodus startet eine In-Memory-Instanz zum Ausprobieren. Der Modus speichert alle Daten im Arbeitsspeicher und eignet sich nicht für den Produktivbetrieb. Ein Container im Dev-Modus startet mit einem Aufruf und stellt das API auf Port 8200 bereit.

bashdocker run --rm -p 8200:8200 \
  -e BAO_DEV_ROOT_TOKEN_ID=dev-only-token \
  -e BAO_DEV_LISTEN_ADDRESS=0.0.0.0:8200 \
  quay.io/openbao/openbao:latest server -dev

Der Parameter -p bildet den Port 8200 auf den Host ab. Über -e gelangen das Root-Token und die Listener-Adresse als Umgebungsvariablen in den Container. Der Befehl server -dev startet den Entwicklungsmodus. Nach dem Start verbindet sich das CLI über zwei Umgebungsvariablen mit der Instanz und prüft deren Zustand.

bashexport BAO_ADDR="http://127.0.0.1:8200"
export BAO_TOKEN="dev-only-token"
bao status

Das Schreiben und Lesen eines Geheimnisses über die Key-Value-Engine erfolgt mit zwei kurzen Befehlen. Der erste legt einen Wert unter einem Pfad ab, der zweite ruft ihn wieder ab.

bashbao kv put secret/my-secret-password password=OpenBao123
bao kv get secret/my-secret-password

Für dauerhafte Installationen stehen native Pakete bereit. Unter Debian, Ubuntu, Fedora und RHEL erfolgt die Installation über die jeweiligen Paketmanager, unter RHEL nach dem Aktivieren des EPEL-Repositoriums.

bashdnf install -y epel-release
dnf install -y openbao

Im Kubernetes-Umfeld bringt ein Helm-Chart die Komponenten in das Cluster. Die anschließende Initialisierung und Entsiegelung der Instanz sowie die Erzeugung des Root-Tokens erfolgen manuell über die OpenBao-CLI oder können durch eigene Automatisierungen (zum Beispiel Skripte oder GitOps-Workflows) durchgeführt werden. Nach der Installation empfiehlt sich eine Härtung gegen das Auslagern von Speicherseiten. Verschlüsselter oder deaktivierter Swap verhindert, dass Geheimnisse über die Auslagerungsdatei nach außen gelangen. Die mitgelieferte systemd-Unit kann den Swap für den OpenBao-Prozess über den Parameter MemorySwapMax=0 deaktivieren. Da OpenBao derzeit den Aufruf von mlock ausgesetzt hat, ist es zusätzlich empfehlenswert, Swap auf Systemebene vollständig zu deaktivieren oder zu verschlüsseln, um ein Auslagern von Geheimnissen zuverlässig zu verhindern.

Fazit

OpenBao bündelt statische und dynamische Geheimnisse, Zertifikate und kryptografische Schlüssel hinter einer verschlüsselten Barriere und steuert den Zugriff identitätsbasiert. Die Trägerschaft durch die Linux Foundation hält das Projekt quelloffen und unabhängig von einem einzelnen Hersteller. Funktionen wie Namespaces und horizontale Lese-Skalierung, die bei der kommerziellen Vorlage zahlungspflichtig sind, gehören zum freien Funktionsumfang. Für Organisationen mit hohem Anspruch an Datenhoheit ergibt die Kombination aus PKCS#11-Anbindung, Audit-Protokoll und offener Lizenz eine belastbare Grundlage.