OpenBao: Secrets-Management für alle – ein ausführlicher Praxisbericht
Ein Open-Source-Fork von HashiCorp Vault – von der Lizenz-Debatte zur Produktionsreife unter dem Dach der Linux Foundation.
Ein Artikel und Erfahrungsbericht von Achim Mertens
1. Die Vorgeschichte: Warum gibt es OpenBao?
In der modernen Cloud-Architektur galt HashiCorp Vault jahrelang als unangefochtener Goldstandard für das Management vertraulicher Daten. Doch im August 2023 riss eine tektonische Verschiebung die Community auseinander: Der Wechsel von der quelloffenen Mozilla Public License (MPL) zur restriktiveren Business Source License (BSL).
Für viele Unternehmen bedeutete das nicht nur rechtliche Unsicherheit, sondern den Verlust digitaler Souveränität – ein drohender Vendor-Lock-in, den niemand wollte.
Die Antwort: Unter dem Dach der Linux Foundation wurde OpenBao als Fork von Vault 1.14.1 ins Leben gerufen. Das Ziel: Eine hochsichere Plattform für das Management sensitiver Daten unter einer echt quelloffenen Lizenz (MPL 2.0) zu garantieren.
2. Die Architektur: Vier Kernkonzepte
2.1 Die Barriere – Zero Trust für den Speicher
Ein Kernmerkmal von OpenBao ist das kompromisslose Misstrauen gegenüber der Infrastruktur. Das Konzept der "Barrier" etabliert einen Zero-Trust-Ansatz für den Storage-Layer. OpenBao geht davon aus, dass jedes Speicher-Backend (egal ob Raft, PostgreSQL oder eine Cloud-Disk) grundsätzlich als kompromittiert zu betrachten ist.
So funktioniert es:
- Bevor Daten die Barriere in Richtung Speicher verlassen, werden sie verschlüsselt
- Innerhalb der Barriere liegt der Root Key, der erst nach dem "Unsealing" zugänglich wird
- Der Root Key selbst ist Shamir-gesplittet (dazu später mehr)
- Selbst bei physischem Diebstahl der Datenträger können keine Klartextdaten extrahiert werden
App ruft API auf → Barriere entschlüsselt → Daten aus Storage
← Barriere verschlüsselt ← Daten zurück
2.2 Dynamische Secrets – Credentials mit Verfallsdatum
Statische Anmeldedaten sind eines der größten Risiken moderner IT-Sicherheit. Ein Datenbank-Passwort, das drei Jahre lang gültig ist, ist eine tickende Zeitbombe.
OpenBao begegnet diesem Problem mit dynamischen Secrets und einem konsequenten Lease-basierten Lifecycle:
- Eine App fordert Zugangsdaten an
- OpenBao generiert sie on-demand (z.B. einen temporären DB-User)
- Die Credentials bekommen eine Lebensdauer (z.B. 1 Stunde)
- Nach Ablauf: automatische "Selbstzerstörung" – der User wird gelöscht
Der strategische Vorteil: Das Zeitfenster für den Missbrauch gestohlener Keys wird von Monaten auf Minuten reduziert. Gleichzeitig entsteht ein lückenloser Audit-Trail, der jedes Secret einer authentifizierten Identität zuordnet.
2.3 Shamir's Secret Sharing – Vertrauen teilen
Ein versiegelter OpenBao-Server ist eine Festung. Um ihn zu entsiegeln, nutzt das System standardmäßig das Shamir's Secret Sharing-Verfahren.
Das Prinzip:
- Der Master-Key wird in Shards (Bruchstücke) aufgeteilt
- Eine definierte Anzahl (Threshold) wird zur Entsiegelung benötigt
- Beispiel: 5 Shards, Threshold 3 → 3 von 5 Schlüsselwächtern müssen zusammenkommen
Das ist nicht nur Technik, sondern ein Multi-Party-Authorization-Protokoll. Kein einzelner Administrator kann das System im Alleingang kompromittieren. Für hochautomatisierte Umgebungen bietet OpenBao Auto-Unseal via Cloud-KMS oder HSM.
2.4 Identity-based Access – Wer statt Wo
OpenBao nutzt einen Identity-based Access-Ansatz. Zugriffe werden nicht an IP-Adressen, sondern an Identitäten gebunden. Das System kennt:
- Auth Methods: Kubernetes-Service-Accounts, OIDC (z.B. Keycloak), LDAP, Token
- Entities: Einem Menschen/Gerät zugeordnete Identität
- Policies: HCL-basierte Regeln nach dem Deny-by-Default-Prinzip
path "secret/data/produktion/*" {
capabilities = ["read", "list"]
}
Policies folgen einer komplexen Priority-Logik: Der Longest-Prefix Match gewinnt, bei identischen Pfaden werden die Berechtigungen als Union behandelt.
3. Hands-on: Vom Raspberry Pi zur Produktion
3.1 Installation mit Podman
Der Einstieg ist überraschend einfach. Ich habe OpenBao auf einem Raspberry Pi 5 (8 GB RAM) mit Podman gestartet:
Image laden:
podman pull quay.io/openbao/openbao-ubi:latest
Container starten:
podman run --name openbao -p 8200:8200 quay.io/openbao/openbao-ubi server -dev
Der Server startet im Development-Mode – sofort einsatzbereit, unsealed, mit einem Root-Token für den ersten Zugriff.
Ausgabe beim Start:
Version: OpenBao v2.5.4
Storage: inmem
Unseal Key: [KEY]
Root Token: s.[TOKEN]
3.2 Bash-Funktion für den CLI-Zugriff
Damit man nicht jedes Mal den ganzen Podman-Befehl tippen muss, habe ich mir eine Funktion in der .bashrc eingerichtet:
bao_cli() {
podman run --rm -it \
-e BAO_ADDR=http://host.docker.internal:8200 \
-e BAO_TOKEN=s.[TOKEN] \
quay.io/openbao/openbao-ubi "$@"
}
3.3 Erste Schritte mit der CLI
Secret speichern:
bao_cli kv put secret/test api_key=*** username=achim
Secret auslesen:
bao_cli kv get secret/test
# Ausgabe: api_key=abc123, username=achim
Einzelnes Feld:
bao_cli kv get -field=username secret/test
# → achim
Alle Secrets auflisten:
bao_cli kv list secret/
Versionen verwalten:
# Alte Version lesen
bao_cli kv get -version=1 secret/test
# Soft-Delete (Version bleibt erhalten)
bao_cli kv delete secret/test
# Metadata anzeigen (alle Versionen)
bao_cli kv metadata get secret/test
3.4 Zugriff über die REST-API (curl)
Der wohl wichtigste Teil für die Integration in bestehende Systeme – der API-Zugriff via curl:
Basis: http://localhost:8200/v1/ mit Header X-Vault-Token: [TOKEN]
Status prüfen:
curl http://localhost:8200/v1/sys/health | python3 -m json.tool
# → initialized: true, sealed: false
Secret schreiben:
curl -s -X POST \
-H "X-Vault-Token: [TOKEN]" \
-H "Content-Type: application/json" \
-d "{\"data\": {\"api_key\": \"abc123\", \"username\": \"achim\"}}" \
http://localhost:8200/v1/secret/data/test
Secret lesen:
curl -s \
-H "X-Vault-Token: [TOKEN]" \
http://localhost:8200/v1/secret/data/test
Secrets auflisten (LIST):
curl -s -X LIST \
-H "X-Vault-Token: [TOKEN]" \
http://localhost:8200/v1/secret/metadata/
Versioniert lesen:
curl -s -H "X-Vault-Token: [TOKEN]" \
"http://localhost:8200/v1/secret/data/test?version=2"
3.5 Policies in der Praxis
Ein Token mit eingeschränkten Rechten erzeugen und testen:
# Policy-Datei (nur Lesen auf alles)
cat > /tmp/readonly.hcl << 'END'
path "secret/data/*" { capabilities = ["read", "list"] }
END
# Policy einspielen
bao_cli policy write readonly /tmp/readonly.hcl
# Neuen Token mit dieser Policy
TOKEN_NEW=$(bao_cli token create -policy=readonly -field=token)
# Test: Lesen klappt
curl -s -H "X-Vault-Token: $TOKEN_NEW" \
http://localhost:8200/v1/secret/data/test
# Test: Schreiben sollte fehlschlagen
curl -s -X POST -H "X-Vault-Token: $TOKEN_NEW" \
-H "Content-Type: application/json" \
-d '{"data": {"sollte": "nicht klappen"}}' \
http://localhost:8200/v1/secret/data/test
# → permission denied
Verfügbare Capabilities im Überblick:
| Capability | Bedeutung | HTTP-Methode |
|---|---|---|
| read | Daten lesen | GET |
| create | Anlegen | POST/PUT |
| update | Aktualisieren | POST/PUT |
| delete | Soft-Delete | DELETE |
| list | Auflisten | LIST |
| sudo | Admin-Aktionen | – |
| deny | Explizit verweigern | – |
Berechtigungen prüfen (ohne auszuprobieren):
bao_cli token capabilities [TOKEN] secret/data/test
# → [read, list]
4. Troubleshooting & Log-Analyse
Container-Logs live
podman logs -f openbao
Log-Level
| Level | Beschreibung |
|---|---|
| trace | Maximal detailliert (jede API-Operation) |
| debug | Detaillierte Diagnose |
| info | Normalbetrieb (Standard) |
| warn | Warnungen + Fehler |
| error | Nur Fehler |
Health-Check
curl -so /dev/null -w "%{http_code}" http://localhost:8200/v1/sys/health
# 200 = initialized + unsealed
# 503 = sealed (muss entsiegelt werden)
# 501 = nicht initialisiert
Status verstehen
bao_cli status
# Zeigt: Seal Type, Initialized, Sealed, Version, Storage Type
Häufige Fehler
| Fehler | Ursache | Lösung |
|---|---|---|
| permission denied | Token hat keine Berechtigung | Policy prüfen |
| unsupported path | Falscher API-Pfad | kv list zum Prüfen |
| no handler for route | Engine nicht gemountet | bao secrets list |
| connection refused | Container läuft nicht | podman start openbao |
| TLS handshake error | HTTPS statt HTTP | http:// verwenden |
| invalid request | Falscher Token/JSON-Format | Token + Syntax prüfen |
5. Migration von Vault zu OpenBao
Falls ihr bereits Vault nutzt und wechseln möchtet:
- API-Kompatibilität: Für bestehende Workflows bleibt die API kompatibel (getestet ab OpenBao 2.2.0)
- Token-Präfixe ändern sich:
- Vault:
hvs.,hvb.,hvr. - OpenBao:
sbr.(neue Tokens) - Alte Tokens laufen ab – wichtig für Regex-Prüfungen!
- Vault:
- mlock entfernen: OpenBao unterstützt seit 2.0.0 kein mlock mehr →
disable_mlockaus Config löschen - Audit-Permissions: Bei übernommenen Log-Dateien manuelles chown nötig
6. Die Roadmap: Was kommt 2025-2026?
OpenBao ist kein reiner Maintenance-Fork. Das Projekt entwickelt sich aktiv weiter:
- Horizontal Scalability: Read Scalability für massive Enterprise-Umgebungen
- Lazy Loading von Mounts: Namespaces werden nur bei Bedarf geladen → bessere Ressourcennutzung
- Modernisierung der UI: Wechsel von EmberJS zu React
- OSS-Framework: Operator Experience, Scalability, Sustainability
7. Was ich gelernt habe
- Dev-Mode ≠ Produktion – im Dev-Mode bleiben Daten nur im RAM, ein Neustart löscht alles
- Token are power – der Root-Token kann alles, produktionstaugliche Tokens bekommen minimale Policies
- Versionierung ist aktiv – überschriebene Secrets bleiben als alte Version erhalten
- Policies sind das Herz – Zugriffskontrolle via Deny-by-Default granular steuern
- Dynamische Secrets sind ein Gamechanger für Security – Credentials mit Ablaufdatum
- Shamir-Secret-Sharing verhindert Einzelkämpfer-Zugriff auf sensible Systeme
8. Fazit
OpenBao hat sich in Rekordzeit von einer defensiven Reaktion auf einen Lizenzwechsel zu einer Speerspitze der Open-Source-Innovation entwickelt. Durch die Schirmherrschaft der Linux Foundation ist das Projekt vor den Launen einzelner kommerzieller Akteure geschützt.
Fünf Dinge, die ihr mitnehmen solltet:
- Open Source unter MPL 2.0 – keine bösen Überraschungen mehr
- Zero-Trust-Architektur – OpenBao vertraut dem Speicher nicht
- Dynamische Secrets – Credentials werden auf Zeit vergeben
- Policies – Zugriffskontrolle auf Pfad-Ebene, Deny-by-Default
- API-kompatibel zu Vault – Migration ist realistisch machbar
Für Unternehmen bedeutet der Wechsel zu OpenBao die Rückkehr zur technologischen Souveränität bei gleichzeitigem Zugriff auf moderne Features wie Identity-based Access und skalierbare Verschlüsselung.
Zum Weiterlesen:
Geschrieben von 
