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
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.
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:
App ruft API auf → Barriere entschlüsselt → Daten aus Storage
← Barriere verschlüsselt ← Daten zurück
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:
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.
Ein versiegelter OpenBao-Server ist eine Festung. Um ihn zu entsiegeln, nutzt das System standardmäßig das Shamir's Secret Sharing-Verfahren.
Das Prinzip:
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.
OpenBao nutzt einen Identity-based Access-Ansatz. Zugriffe werden nicht an IP-Adressen, sondern an Identitäten gebunden. Das System kennt:
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.
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]
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 "$@"
}
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
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"
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]
podman logs -f openbao
| Level | Beschreibung |
|---|---|
| trace | Maximal detailliert (jede API-Operation) |
| debug | Detaillierte Diagnose |
| info | Normalbetrieb (Standard) |
| warn | Warnungen + Fehler |
| error | Nur Fehler |
curl -so /dev/null -w "%{http_code}" http://localhost:8200/v1/sys/health
# 200 = initialized + unsealed
# 503 = sealed (muss entsiegelt werden)
# 501 = nicht initialisiert
bao_cli status
# Zeigt: Seal Type, Initialized, Sealed, Version, Storage Type
| 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 |
Falls ihr bereits Vault nutzt und wechseln möchtet:
hvs., hvb., hvr.sbr. (neue Tokens)disable_mlock aus Config löschenOpenBao ist kein reiner Maintenance-Fork. Das Projekt entwickelt sich aktiv weiter:
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:
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 
