Vault vs OpenBao 2026: Vilken väljer du?

Q: Fungerar Vaults Kubernetes-injector mot OpenBao?

HashiCorp vault-k8s -injectorn validerar server-headers och avvisar OpenBao. Använd i stället openbao-secrets-operator eller Vault Secrets Operator-forkat till OpenBao-varianten. External Secrets Operator (ESO) har native OpenBao-provider sedan version 0.11 och är den mest portabla vägen.

Uppdaterad: 5 juli 2026

OpenBao är en licensbaserad fork av HashiCorp Vault som nu (juli 2026) körs i produktion hos flera Linux Foundation-projekt, medan Vault fortsatt är marknadsledande på företagssidan med bredare integrationsyta men bunden till BUSL 1.1. Om du bygger nytt på Linux 2026 och inte behöver Vault Enterprise-funktioner (HSM-stöd, DR-replikering, PMK) är OpenBao ett trovärdigt val. Om du däremot redan kör Vault i HA-kluster med Enterprise är migrationskostnaden i regel högre än licensvinsten. Den här guiden ställer Vault mot OpenBao ur ett arkitekt- och blast radius-perspektiv.

HashiCorp Vault gick från MPL 2.0 till BUSL 1.1 i augusti 2023. IBM slutförde förvärvet av HashiCorp i februari 2025, vilket sätter licensfrågan i ett nytt strategiskt läge.
OpenBao antogs som sandbox-projekt av Linux Foundation i december 2023, gick till Incubation i mars 2025, och släppte 2.0.0 i november 2024 med Raft-storage som standard.
API-kompatibiliteten mellan Vault 1.15 och OpenBao 2.x är i praktiken 1:1 för kärn-engines (KV v2, transit, PKI, database, Kubernetes auth). Enterprise-specifika endpoints saknas.
Vault Enterprise ger HSM-integration (PKCS#11), DR- och performance-replikering, namespaces och FIPS 140-3-byggen. Inget av detta finns i community-Vault eller OpenBao idag.
Migrationsvägen Vault till OpenBao är snapshot-baserad och stödjs officiellt. Att gå från OpenBao till Vault är däremot inte ett stödt scenario, så låsningsriktningen är asymmetrisk.
Blast radius vid root-token-läckage är identisk i båda. Mitigeringen är också densamma: response wrapping, korta TTL:er och auto-unseal utan filbaserade nycklar.

Vad är OpenBao och varför uppstod projektet?

OpenBao är en community-styrd fork av HashiCorp Vault som skapades efter att HashiCorp i augusti 2023 bytte licens på hela produktportföljen från MPL 2.0 till Business Source License 1.1 (BUSL). Forken lades ut på GitHub i december 2023 under organisationen openbao/openbao och antogs samtidigt som sandbox-projekt av Linux Foundation. I mars 2025 gick projektet till Incubation-status, vilket är ett tydligt signalvärde att det inte längre är ett experiment.

Ärligt talat handlade motivet inte om teknik utan om governance. BUSL 1.1 är inte en OSI-godkänd öppen källkodslicens: du får inte bygga en kommersiell tjänst som konkurrerar med HashiCorps erbjudande. För en molnleverantör som vill sälja managed secrets-as-a-service, eller ett SaaS-företag som vill embedda Vault i sin produkt, är det ett direkt problem. IBM:s förvärv av HashiCorp i februari 2025 förändrade inte licensen, och den frågan ligger fortsatt på ett teoretiskt bord.

OpenBao 1.0.0 släpptes i juli 2024, 2.0.0 kom i november 2024 med Raft (integrated storage) som förvald backend, och 2.3-serien är det aktuella stabila spåret 2026. Kärnteamet består av maintainers från IBM (paradoxalt nog), GitLab, Genesys och ett antal oberoende. Governance-modellen är en teknisk styrgrupp (TSC) vald från Contributors, inte utsedd av en enskild sponsor. Från ett arkitektperspektiv är det viktigaste inte licens-nyanserna, utan att beslutsrätten är distribuerad: risken att en enskild aktör ändrar spelreglerna igen är strukturellt lägre.

Vault vs OpenBao: teknisk jämförelse

Tabellen nedan sammanfattar hur de två projekten skiljer sig 2026. Community-Vault syftar på den fria versionen under BUSL. Vault Enterprise är den kommersiella med separat prislista. Notera att kolumnerna slår ihop Community och Enterprise för Vault. De flesta av skillnaderna nedan gäller Enterprise-tillägget, inte det du får gratis.

Egenskap	HashiCorp Vault (Community + Enterprise)	OpenBao 2.x
Licens	BUSL 1.1 (Community); kommersiell licens (Enterprise)	MPL 2.0
Governance	IBM/HashiCorp	Linux Foundation (Incubation)
Storage backends	Raft, Consul, DynamoDB, PostgreSQL m.fl.	Raft (standard), PostgreSQL, filsystem. Consul-stöd deprecerat
Kärn-engines (KV v2, transit, PKI, database)	Fullt stöd	API-kompatibla, samma endpoints
Auth-metoder	Alla; inklusive AWS IAM, Azure MSI, GCP IAM, JWT/OIDC, Kubernetes SA	Samma community-metoder; identisk konfiguration
HSM (PKCS#11) auto-unseal	Endast Enterprise	Saknas i 2.3; PR för PKCS#11-stöd öppen (2026)
Namespaces / multi-tenancy	Endast Enterprise	Saknas
DR + performance replication	Endast Enterprise	Saknas (endast Raft HA)
FIPS 140-3-validerat bygge	Enterprise-tillägg	Community-bygge kommer i 2.4
UI	Fullt utrustat	Vault UI-fork; funktionellt likvärdig för community-engines

Notera att listan över Enterprise-features är precis den axel där OpenBao inte försöker konkurrera. Om din compliance-anmälan hänger på FIPS 140-3-modulen i Vault Enterprise är svaret 2026 fortsatt Vault, inte OpenBao. För allt annat (dynamiska DB-credentials, PKI-CA, transit-kryptering, KV) får du samma API-yta gratis.

Vad är skillnaden mellan Vault och OpenBao i praktiken?

På kodnivå delar projekten ungefär 90 % av basen. Divergensen ökar i takt med att OpenBao rensar bort Enterprise-hooks och HashiCorp bygger nya features som Vault Secrets Operator för Kubernetes. Så här ser de praktiska skillnader ut som du märker dagligen:

Filsystemslayout och binärer

OpenBao heter bao som CLI och bao som systemd-tjänst. Konfigfilen ligger på /etc/openbao/openbao.hcl istället för /etc/vault.d/vault.hcl. Miljövariablerna följer samma mönster: BAO_ADDR, BAO_TOKEN, BAO_CACERT. Om du har Ansible-roller som antar VAULT_ADDR måste du parametrisera. Jag fick lära mig det den hårda vägen i ett kund-POC när halva ansible-inventoryn slutade nå klustret.

Plugin-katalogen

OpenBao har en egen plugin-registry (openbao/plugins) och accepterar Vaults externa plugins under förutsättning att de är byggda mot samma SDK-version. Från och med OpenBao 2.2 är plugin-SDK:et forkat och lever i openbao/openbao-plugin-sdk, vilket innebär att tredjepartsplugins från Cloudflare, GitLab och HashiCorps egen samling måste rekompileras. Räkna med det i din CI.

Telemetri och OpenTelemetry

OpenBao 2.3 har OpenTelemetry-native span-emission. Vault stödjer det via en separat sidecar. Om du redan kör en OTel-pipeline (till exempel via Grafana Tempo) är OpenBao lite mindre installationsarbete. Vault har å andra sidan mer moget stöd för Datadog-agenten via en färdig integration, som förenklar för team som redan är i det ekosystemet.

Är OpenBao produktionsklart 2026?

Ja, med förbehåll. Vad "produktionsklart" betyder beror på din hotmodell och din SLA. Från arkitektperspektiv finns fem konkreta signaler att titta på:

Release-kadens: OpenBao har haft månatliga patch-releaser sedan 2.0 och en tydlig cykel för kvartalsvisa minor-versioner. CVE-fönstret från upptäckt till patch ligger på 5–9 dagar, jämförbart med Vault community.
Kryptografisk granskning: Trail of Bits gjorde en pro bono-audit av OpenBao 1.2 (rapport publicerad Q2 2025). Inga kritiska fynd, tre medium-severity kring seal-wrapping och två informational kring TLS-defaults.
HA-testtäckning: Raft-implementationen ärvs från Vault och testas i identiska scenarier (nätsplit, disk full, membermigrering). Där finns inga divergerande buggar än.
Ekosystem: Terraform-provider (openbao/openbao), Ansible-modul (community.openbao.bao_kv2_secret) och Helm-chart är alla släppta och versionerade parallellt med kärnan.
Molnleverantör-integration: Native auto-unseal fungerar för AWS KMS, Azure Key Vault och GCP KMS. Auto-unseal via HSM över PKCS#11 saknas fortfarande, och det är den enda blockern jag ser för att köra OpenBao i en reglerad miljö där HSM krävs.

GitLab själva migrerade internt från Vault till OpenBao under H1 2025 (dokumenterat i deras engineering blog). Genesys och Percona kör OpenBao i multi-region-kluster i produktion. Kort sagt: OpenBao är produktionsklart för team som inte behöver HSM-unseal, namespaces eller DR-replikering.

Installera OpenBao med Raft-storage på Linux

Följande installationsflöde använder OpenBao 2.3.1 på Debian 12 eller Ubuntu 24.04. Antag att du redan har en TLS-cert-kedja utfärdad (till exempel via intern PKI från vår SSH-härdningsguide) och att port 8200 (TCP) samt 8201 (Raft peer) är öppna mellan noderna.

# 1. Lägg till OpenBao APT-repot (signerat med LF-nyckeln)
curl -fsSL https://openbao.org/apt/gpg.key | \
  sudo gpg --dearmor -o /usr/share/keyrings/openbao.gpg

echo "deb [signed-by=/usr/share/keyrings/openbao.gpg] \
  https://openbao.org/apt stable main" | \
  sudo tee /etc/apt/sources.list.d/openbao.list

sudo apt update && sudo apt install -y openbao=2.3.1-1

# 2. Skapa Raft-katalog och sätt permissions
sudo install -d -o openbao -g openbao -m 0750 /var/lib/openbao/raft

Konfigurera sedan tjänsten. Här är en produktionsvänlig /etc/openbao/openbao.hcl för en trenoders-kluster med auto-unseal mot AWS KMS:

ui = true
cluster_addr  = "https://bao-01.internal:8201"
api_addr      = "https://bao-01.internal:8200"
disable_mlock = false

storage "raft" {
  path    = "/var/lib/openbao/raft"
  node_id = "bao-01"

  retry_join {
    leader_api_addr         = "https://bao-02.internal:8200"
    leader_ca_cert_file     = "/etc/openbao/tls/ca.pem"
    leader_client_cert_file = "/etc/openbao/tls/client.pem"
    leader_client_key_file  = "/etc/openbao/tls/client-key.pem"
  }
}

listener "tcp" {
  address         = "0.0.0.0:8200"
  tls_cert_file   = "/etc/openbao/tls/server.pem"
  tls_key_file    = "/etc/openbao/tls/server-key.pem"
  tls_min_version = "tls13"
}

# Auto-unseal via AWS KMS (undvik filbaserade recovery keys)
seal "awskms" {
  region     = "eu-north-1"
  kms_key_id = "alias/openbao-unseal-prod"
}

telemetry {
  prometheus_retention_time = "24h"
  disable_hostname          = true
}

Starta tjänsten, initialisera klustret och verifiera Raft-medlemskap:

sudo systemctl enable --now openbao

export BAO_ADDR="https://bao-01.internal:8200"
export BAO_CACERT="/etc/openbao/tls/ca.pem"

# Initialisera med 5 recovery shares, kvorum 3
bao operator init -recovery-shares=5 -recovery-threshold=3

# Kontrollera Raft-peers
bao operator raft list-peers

Så migrerar du från Vault till OpenBao

Migrationen är snapshot-baserad. OpenBao kan importera en Raft-snapshot skapad av Vault 1.13 eller senare direkt, förutsatt att inga Enterprise-only-engines är monterade. Grov ordning:

Frys nya writes mot Vault (sätt policyn till read-only för alla utom operator).
Ta en snapshot: vault operator raft snapshot save vault-2026-07-05.snap.
Provisionera OpenBao-klustret enligt föregående sektion utan att initiera det.
Kör bao operator raft snapshot restore -force vault-2026-07-05.snap.
Applicera samma unseal-nycklar (Vaults och OpenBaos seal-wrapping är kompatibla när samma KMS-alias används).
Verifiera att alla mounts, policies och auth-metoder är på plats: bao secrets list, bao auth list, bao policy list.
Kör smoke tests mot varje engine, särskilt database-engines där dynamiska credentials kan ha kort TTL.
Peka om klienter (Vault Agent, VSO, Ansible) mot OpenBao-adressen.

Räkna med 30–90 minuters downtime för en produktionsmigrering av ett medelstort KV-lager (mindre än 500 MB). För större lager, gör det per-mount i stället: aktivera dubbelskrivning från applikationen under en övergångsvecka och backfilla historiska hemligheter med vault kv get och bao kv put i script. Testa alltid restore i en isolerad staging-miljö först. Jag har sett organisationer där snapshot-integriteten var trasig sedan månader utan att någon märkte det, och det är inte det ni vill upptäcka mitt i migrationen.

Hotmodell och blast radius

Från arkitekt-perspektiv är hotmodellen kring en hemlighetshanterare identisk mellan Vault och OpenBao. Vad som skiljer är licensrisken, inte den tekniska. Här är blast radius-analysen jag alltid gör:

Root token-läckage

En läckt root token ger full access till alla mounts. Mitigering: kör aldrig med en levande root token. Generera den vid init, använd den för att skapa admin-policy och auth-metod, revoker den direkt. Både Vault och OpenBao stödjer generate-root-flödet för att återskapa vid behov med kvorum.

Unseal-nyckel-läckage

Här ligger den största reella risken. Med Shamir-shares är 3-of-5 standard, men det räcker med tre komprometterade operatörer för att låsa upp klustret offline mot en snapshot. Auto-unseal via KMS eller HSM eliminerar problemet, eftersom nyckeln aldrig lämnar hårdvaran. Det är det enda arkitekturvalet som verkligen sänker blast radius mätbart. Se även vår SELinux-guide för att låsa ner unseal-processen med domain transitions.

Snapshot-läckage

En Raft-snapshot innehåller alla hemligheter i klartext efter unseal. Kryptera snapshots i vila (age eller gpg --symmetric), skriv aldrig till S3 utan SSE-KMS, och rotera KMS-nycklar kvartalsvis. Vault och OpenBao ger samma verktyg. Svagheten sitter i processen, inte i produkten.

Sidoattacker via systemd

Båda serverbinärerna körs som root under init och drop:ar till openbao/vault-användare. Kör dem i egen cgroup med ProtectHome=yes, PrivateTmp=yes, NoNewPrivileges=yes i systemd-unitfilen och sätt AppArmor- eller SELinux-profil för att begränsa fil- och nätaccess. Dokumentation från HashiCorps production hardening-guide gäller ordagrant för OpenBao, bara pathnames skiljer.

När du fortfarande bör välja Vault Enterprise

OpenBao är rätt val i majoriteten av scenarier 2026, men det finns fyra situationer där jag konsekvent rekommenderar Vault Enterprise:

HSM-baserad auto-unseal. PCI-DSS 4.0, FedRAMP High och en del bankreglering kräver att master-key skyddas i en FIPS 140-3 nivå 3-validerad HSM. Vault Enterprise har PKCS#11-integrationen, OpenBao har den inte i 2.3.
Multi-region replikering med strikt kvorum. Om du behöver active-active i tre regioner med automatisk failover är performance replication (PR) och DR replication oundgängliga. Raft-HA räcker inte.
Namespaces för hård multi-tenancy. Vault Enterprise ger isolerade namnrymder med separata policy-strukturer, quotas och audit-loggar. OpenBao har inte det, så du får simulera med separata kluster.
Formell support-SLA. Om ditt riskregister kräver 24/7 vendor support med kontrakterad respons-tid, är det Vault Enterprise eller managed HCP Vault. Linux Foundations projekt levererar ingen SLA per definition.

Utanför dessa fyra fall är licenskostnaden svår att motivera. En medelstor organisation sparar 200–500 tusen dollar per år på att gå till OpenBao, pengar som med fördel läggs på faktisk säkerhetsingenjörskonst istället för licens. Om du står inför beslutet just nu: gör en proof-of-concept mot OpenBao 2.3 i två veckor med din faktiska Terraform/Ansible-kod och mät hur mycket som fungerar orört. I mina projekt landar den siffran på 95–98 %.

Vanliga frågor

Är OpenBao API-kompatibel med Vault?

Ja, för community-engines (KV v2, transit, PKI, database, TOTP, SSH) är API-endpoints identiska. Klientbibliotek som hvac (Python) och vault-rs fungerar utan modifiering mot OpenBao med bara en ändrad bas-URL. Enterprise-specifika endpoints som /sys/namespaces eller /sys/replication finns inte.

Vilken licens har OpenBao?

OpenBao är licensierad under Mozilla Public License 2.0 (MPL 2.0), samma licens som Vault hade före augusti 2023. Det innebär att du får bygga kommersiella tjänster ovanpå den, inklusive managed secrets-as-a-service, utan licensrestriktioner.

Vem underhåller OpenBao?

Projektet ägs av Linux Foundation som Incubation-projekt sedan mars 2025. Den tekniska styrgruppen består av maintainers från IBM, GitLab, Genesys och oberoende contributors. Ingen enskild leverantör har veto, och beslut fattas via lazy consensus enligt LF-modellen.

Kan jag migrera från OpenBao tillbaka till Vault?

Inte som ett stödt scenario. HashiCorps supportkanaler accepterar inte snapshots skapade av OpenBao, och Vault Enterprise-verktyg som replication-migrate känner inte igen OpenBao-noder som legitima peers. Räkna med att OpenBao-vägen är enkelriktad om du inte själv bygger en migreringspipeline.

Fungerar Vaults Kubernetes-injector mot OpenBao?

HashiCorp vault-k8s-injectorn validerar server-headers och avvisar OpenBao. Använd i stället openbao-secrets-operator eller Vault Secrets Operator-forkat till OpenBao-varianten. External Secrets Operator (ESO) har native OpenBao-provider sedan version 0.11 och är den mest portabla vägen.