OpenBao: Linux-Foundation-Fork von HashiCorp Vault unter MPL-2.0

Was ist OpenBao?

OpenBao ist ein Community-Fork von HashiCorp Vault, gegründet im Dezember 2023 als direkte Reaktion auf den Lizenz-Wechsel von Vault von MPL-2.0 auf Business Source License 1.1. Das Projekt wurde im April 2024 in die Linux Foundation aufgenommen und steht seitdem unter deren Governance. Mai 2026 ist OpenBao in Version 2.x stabil und produktionsreif, mit aktiver Entwicklung durch eine Community aus IBM, GitLab, Mountpoint, IONOS, und einer Reihe von Cloud-Native-Anbietern.

Der Fork-Punkt ist Vault 1.14 -- die letzte Version unter MPL-2.0-Lizenz. Seit dem Fork hat OpenBao eigene Releases mit Bugfixes, Sicherheits-Patches und neuen Features veröffentlicht. Mai 2026 hat OpenBao eine eigene Roadmap mit Fokus auf Cloud-Native-Integration, Kubernetes-Operator-Tooling und Open-Standards-First. Funktional ist OpenBao etwa 90 Prozent von HashiCorp Vault: alle wichtigen Secrets-Engines (KV v2, Database, PKI, AWS, Transit), alle Auth-Methoden (AppRole, Kubernetes, OIDC, GitHub), Auto-Unseal via Cloud-KMS oder Shamir-Keys, Audit-Devices, HA-Cluster mit Raft-Storage.

Was Vault hat und OpenBao (noch) nicht: einige Enterprise-Features wie HSM-Auto-Unseal, Performance-Replication zwischen mehreren Vault-Clustern, FIPS-140-2-zertifizierte Builds, MFA-Push-Notifications. Für Standard-CH-KMU-Setups irrelevant; für FINMA-regulierte Banken-Treuhand mit HSM-Pflicht eine Lücke.

Die Lizenz MPL-2.0 ist Mozilla Public License 2.0 -- eine voll OSI-zertifizierte Open-Source-Lizenz mit copyleft auf Datei-Ebene. Sie erlaubt kommerzielle Nutzung ohne Einschränkung, erlaubt das Forken und Weiterverkaufen als Service (was BSL 1.1 untersagt) und erlaubt das Mischen mit proprietärem Code. Für CH-KMU mit OSS-Compliance-Anforderungen oder für Cloud-Anbieter, die ein Vault-ähnliches Produkt anbieten wollen, ist OpenBao die einzige Option.

Die Migration von Vault zu OpenBao ist drop-in für fast alle Use Cases: gleiche API-Endpoints, gleiche CLI (openbao statt vault), gleiche HCL-Syntax für Policies, gleiche Storage-Backends. Backup mit vault operator raft snapshot save lässt sich in OpenBao mit openbao operator raft snapshot restore einspielen. Im Migrationspfad behält man die Investition in Policies, Engines und Integrationen.

Warum es für OSS-strenge CH-KMU zählt

OpenBao ist Mai 2026 in vier konkreten Szenarien die richtige Wahl gegenüber Vault.

Strikte OSS-Politik: Wenn das KMU eine Compliance-Vorgabe hat, dass nur OSI-zertifizierte Open-Source-Lizenzen eingesetzt werden dürfen, ist Vault unter BSL 1.1 nicht mehr akzeptabel. Diese Vorgabe ist häufig bei öffentlich-rechtlichen Institutionen, Bildungseinrichtungen, NGOs, oder Mandanten mit eigener OSS-Politik. OpenBao unter MPL-2.0 erfüllt die Vorgabe vollständig.

Vendor-Lock-In-Risiko reduzieren: HashiCorp wurde im März 2024 von IBM gekauft. Die strategische Ausrichtung von Vault unterliegt damit IBM-Konzernpolitik, mit potenziell anderen Prioritäten als bei einer unabhängigen HashiCorp. Linux-Foundation-Governance ist neutral -- kein Einzelunternehmen kann die Roadmap dominieren. Für CH-KMU mit langfristiger Planung (10+ Jahre) ist das ein relevanter Faktor.

Kommerzielle Wiedernutzung im SaaS-Stack: Wer ein eigenes Cloud-Produkt baut, das Secrets-Management als Service anbietet (z.B. ein Treuhand-SaaS mit eingebauter Vault-API für Mandanten), kann Vault unter BSL 1.1 nicht verwenden. OpenBao unter MPL-2.0 erlaubt das ohne Einschränkung. Praktisch relevant für alle CH-KMU, die einen eigenen White-Label-Service mit Secrets-Funktionalität planen.

Migration aus Vault BSL ohne Funktions-Verlust: KMU, die Vault unter MPL-2.0 in Produktion haben und unter BSL keine neuen Updates einspielen wollen, können mit minimalem Aufwand auf OpenBao migrieren. Drop-in-API, gleiche CLI-Befehle (openbao statt vault), gleiche HCL-Policies. Snapshot-Migration in 1-2 Stunden möglich.

revFADP-Anforderungen: OpenBao erfüllt alle revFADP-Anforderungen, die Vault erfüllt -- Audit-Trail, Zugriffs-Logs, Rotation, Compromise-Antwort. Der Schweizer EDÖB hat keine Präferenz für eine bestimmte Implementierung, solange die Schutzmassnahmen dem Stand der Technik entsprechen. OpenBao ist Stand der Technik 2026.

Setup und Migration von Vault

OpenBao läuft auf der gleichen Infrastruktur wie Vault. Setup-Aufwand und Operations-Aufwand sind identisch. Wir zeigen Docker-Compose und den Vault-zu-OpenBao-Migrationspfad.

```yaml version: "3.8" services: openbao: image: openbao/openbao:2.0 container_name: openbao restart: unless-stopped cap_add: - IPC_LOCK environment: - BAO_ADDR=http://0.0.0.0:8200 - BAO_LOCAL_CONFIG={"storage":{"raft":{"path":"/openbao/data","node_id":"openbao-1"}},"listener":{"tcp":{"address":"0.0.0.0:8200","tls_disable":1}},"ui":true,"api_addr":"http://openbao:8200","cluster_addr":"https://openbao:8201","disable_mlock":true,"seal":{"awskms":{"region":"eu-central-1","kms_key_id":"alias/openbao-unseal"}}} ports: - "127.0.0.1:8200:8200" volumes: - ./openbao-data:/openbao/data - ./openbao-logs:/openbao/logs command: openbao server -config=/openbao/config/openbao.hcl ```

Initialisierung beim ersten Start: openbao operator init -recovery-shares=5 -recovery-threshold=3 (analog Vault).

Migration von Vault zu OpenBao in 4 Schritten:

1. Vault-Snapshot erstellen: ```bash vault operator raft snapshot save vault-final.snap vault status > vault-final-status.txt vault policy list > vault-policies.txt ```

2. OpenBao-Cluster aufsetzen mit gleichem Storage-Layout, gleichen Unseal-Parametern. Wichtig: OpenBao-Version verwenden, die Vault-1.14-Snapshot lesen kann.

3. Snapshot in OpenBao einspielen: ```bash openbao operator raft snapshot restore vault-final.snap openbao operator unseal <recovery-key-1> openbao operator unseal <recovery-key-2> openbao operator unseal <recovery-key-3> ```

4. Anwendungen umstellen: VAULT_ADDR=https://openbao:8200 statt vault:8200. Bei Vault-Agent: vault-agent funktioniert weiterhin gegen OpenBao, weil API identisch. Alternativ openbao-agent verwenden.

Beispiel KV-Engine für API-Keys (identisch zu Vault): ```bash openbao secrets enable -path=kv kv-v2 openbao kv put kv/openai api_key=sk-proj-xyz... openbao kv get kv/openai ```

AppRole für Server-Auth (identisch zu Vault): ```bash openbao auth enable approle openbao write auth/approle/role/treuhand-app \ token_policies="treuhand-policy" \ token_ttl=1h token_max_ttl=4h ```

Wichtige openbao-CLI-Befehle: openbao status zeigt Cluster-Status. openbao operator raft list-peers zeigt HA-Members. openbao audit list zeigt aktive Audit-Devices. openbao token lookup zeigt Token-Details. openbao token revoke <id> revoked Token sofort.

Integration mit anderen Tools: openbao-agent als Sidecar, OIDC-Auth gegen Authentik/Authelia, Kubernetes-Operator (openbao-secrets-operator) für K8s-Workloads, Terraform-Provider (openbao/openbao) für Infrastructure-as-Code.

OpenBao-Einführung in 5 Schritten

1. 01Entscheidungs-Prüfung: BSL 1.1 vs MPL-2.0 für das KMU bewerten; falls Vault bereits läuft, Migration vs Greenfield-Setup wählen.
2. 02OpenBao-Cluster aufsetzen: 3 Nodes mit Raft-Storage, Auto-Unseal via Cloud-KMS oder Shamir-Keys (3-of-5); openbao operator init und unseal durchführen.
3. 03Secrets-Engines und Auth-Methoden konfigurieren: KV v2, Database, PKI; AppRole, OIDC über Authentik/Authelia; Policies nach Least-Privilege.
4. 04Migration von Vault (falls vorhanden): Snapshot mit vault operator raft snapshot save, Restore mit openbao operator raft snapshot restore, Anwendungen auf neuen Endpoint umstellen.
5. 05Audit, Rotation und Monitoring: Audit-Engine zu Loki/Splunk, statische Secrets alle 90 Tage rotieren, Compromise-Runbook (72h-Meldung) dokumentieren, HA-Cluster-Health monatlich prüfen.

Wann OpenBao statt Vault wählen

OpenBao ist Mai 2026 in vier Konstellationen die bessere Wahl gegenüber Vault.

Strikte OSS-Lizenz-Politik: KMU oder öffentliche Institutionen mit einer Compliance-Vorgabe "nur OSI-zertifizierte Open-Source-Lizenzen". BSL 1.1 ist nicht OSI-zertifiziert, MPL-2.0 ist es. OpenBao ist die einzige direkte Option. Alternative wäre Bitwarden Secrets Manager (GPL-3) -- funktional aber deutlich weniger mächtig.

Multi-Tenant-SaaS-Builds: Wer ein eigenes Produkt baut, das Vault-ähnliche Funktionalität an Mandanten als Service liefert (z.B. Treuhand-SaaS mit Secrets-API für Mandanten-eigenes Tooling), kann Vault unter BSL 1.1 nicht verwenden. OpenBao unter MPL-2.0 ist die einzige praktikable Wahl.

Vendor-Lock-In-Reduktion: KMU mit langfristiger Strategie (10+ Jahre) und Sorge vor IBM-Strategie-Wechseln nach HashiCorp-Acquisition. Linux-Foundation-Governance bietet Neutralität.

Neue Greenfield-Deployments ohne Vault-Historie: Wer 2026 ein Secrets-Management-Setup von Null aufbaut, hat keinen Investitions-Schutz-Grund, BSL-Vault zu wählen. OpenBao ist funktional gleichwertig für 90 Prozent der Use Cases, mit OSS-Lizenz-Vorteil und neutraler Governance.

Vault BSL bleibt die richtige Wahl wenn: (a) HSM-Auto-Unseal Pflicht ist (FINMA-Banken-Treuhand mit HSM-Anforderung); (b) Performance-Replication zwischen multiplen Datacentern benötigt wird; (c) FIPS-140-2-zertifizierte Builds in regulierten US-Umgebungen Pflicht sind; (d) HashiCorp Cloud Platform (HCP Vault) als Managed-Service genutzt wird -- OpenBao Cloud-Variante ist Mai 2026 noch nicht in vergleichbarer Reife verfügbar.

Wann OpenBao nicht reicht

Drei Fälle, in denen OpenBao Mai 2026 nicht die richtige Wahl ist.

FINMA-Banken-Treuhand mit HSM-Pflicht: HashiCorp Vault Enterprise unterstützt HSM-Auto-Unseal via PKCS#11-Interface gegen Hardware-Sicherheitsmodule (Thales, Utimaco, AWS CloudHSM). OpenBao hat das Mai 2026 noch nicht im Standard-Build. Wer FINMA-Hochrisiko-Mandate hat und HSM-Pflicht erfüllen muss, bleibt bei Vault Enterprise.

Managed-Service-Bedarf mit Enterprise-SLA: HashiCorp Cloud Platform (HCP) bietet Vault als Managed-Service mit 99.95-Prozent-SLA, 24/7-Support und IBM-Konzern-Backing. OpenBao Cloud-Varianten gibt es Mai 2026 nur von Klein-Anbietern ohne vergleichbares SLA. Wer Managed-Service mit Enterprise-SLA braucht, geht zu HCP Vault.

Performance-Replication zwischen Datacentern: Vault Enterprise hat aktive Performance-Replication zwischen mehreren Vault-Clustern (z.B. Zürich und Frankfurt). OpenBao kann Disaster-Recovery-Replication, aber keine aktive Performance-Replication mit Read/Write-Forwarding. Für multi-region-Setups mit Latenz-Anforderungen bleibt Vault Enterprise die Wahl.

Generelle Fallen bei OpenBao-Deployments: (a) Annahme, dass alle Vault-Module 1:1 funktionieren -- die meisten ja, einige Spezial-Module (HSM, FIPS, MFA-Push) nicht. (b) Vault-Enterprise-Lizenz mit nach OpenBao migrieren wollen -- die Enterprise-Module sind Closed-Source, OpenBao hat nur die OSS-Module. (c) HashiCorp-Konsultanten beauftragen für OpenBao-Setup -- die meisten kennen das Tool noch nicht in der Tiefe, eigene Linux-Foundation-Maintainer oder unabhängige Berater anfragen. (d) OpenBao-Versions-Sprung von 1.x auf 2.x ohne Test-Phase -- API-Änderungen prüfen, Snapshot-Test-Restore vorab.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. OpenBao -- official documentation · 2026-05
2. OpenBao GitHub -- v2 release notes · 2026-04
3. Linux Foundation -- OpenBao project page · 2026-03
4. HashiCorp -- BSL 1.1 license FAQ · 2026-03
5. OWASP Secrets Management Cheat Sheet · 2026-03