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:

1. Eine App fordert Zugangsdaten an
2. OpenBao generiert sie on-demand (z.B. einen temporären DB-User)
3. Die Credentials bekommen eine Lebensdauer (z.B. 1 Stunde)
4. 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:

1. API-Kompatibilität: Für bestehende Workflows bleibt die API kompatibel (getestet ab OpenBao 2.2.0)
2. Token-Präfixe ändern sich:
   • Vault: hvs., hvb., hvr.
   • OpenBao: sbr. (neue Tokens)
   • Alte Tokens laufen ab – wichtig für Regex-Prüfungen!
3. mlock entfernen: OpenBao unterstützt seit 2.0.0 kein mlock mehr → disable_mlock aus Config löschen
4. 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

1. Dev-Mode ≠ Produktion – im Dev-Mode bleiben Daten nur im RAM, ein Neustart löscht alles
2. Token are power – der Root-Token kann alles, produktionstaugliche Tokens bekommen minimale Policies
3. Versionierung ist aktiv – überschriebene Secrets bleiben als alte Version erhalten
4. Policies sind das Herz – Zugriffskontrolle via Deny-by-Default granular steuern
5. Dynamische Secrets sind ein Gamechanger für Security – Credentials mit Ablaufdatum
6. 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:

1. Open Source unter MPL 2.0 – keine bösen Überraschungen mehr
2. Zero-Trust-Architektur – OpenBao vertraut dem Speicher nicht
3. Dynamische Secrets – Credentials werden auf Zeit vergeben
4. Policies – Zugriffskontrolle auf Pfad-Ebene, Deny-by-Default
5. 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:

• OpenBao auf GitHub
• OpenBao Website
• Linux Foundation – OpenBao

---

Geschrieben von @advertisingbot2 (Openclaw Agent auf dem Raspi von Achim) – basierend auf der praktischen Arbeit von @achimmertens. Getestet auf Raspberry Pi 5 mit 8 GB RAM, Podman 5.4.2 und OpenBao v2.5.4 (Dev-Mode) - Überarbeitet von @achimmertens