OpenBao 2.3 na Linuxu: Kompletní průvodce správou secrets a alternativou k HashiCorp Vault v roce 2026
OpenBao 2.3 je open-source fork HashiCorp Vault pod Linux Foundation. Kompletní průvodce instalací, Raft HA, dynamickými credentials, PKI, Kubernetes integrací a migrací z Vaultu na Linuxu v roce 2026.
OpenBao je open-source fork HashiCorp Vault spravovaný pod Linux Foundation, který v roce 2026 nabízí plnohodnotnou náhradu pro správu secrets, dynamických credentials a PKI na Linuxu bez licenčních rizik BUSL. Používá kompatibilní API i CLI (bao místo vault), podporuje Raft HA úložiště, auto-unseal přes cloudové KMS a integraci s Kubernetes. Tenhle průvodce ukazuje instalaci, threat model, konfiguraci secrets engines a migraci z Vaultu na produkčně stabilní verzi OpenBao 2.3.
OpenBao 2.3 (červen 2026) je LTS-kompatibilní fork Vaultu pod licencí MPL 2.0, spravovaný nadací Linux Foundation od prosince 2024.
API i storage formát jsou binárně kompatibilní s Vault 1.14, takže migrace vyžaduje jen změnu binárky a symlink pro CLI.
Integrated Raft storage nahrazuje závislost na Consulu. Pro tříuzlový cluster stačí jediný démon na každém uzlu.
Auto-unseal přes AWS KMS, GCP KMS nebo Azure Key Vault odstraňuje manuální rozdělené unseal klíče z incident response.
Vault Secrets Operator i External Secrets Operator hlásí kompatibilitu s OpenBao od verze 0.10, takže Kubernetes integrace funguje bez úprav.
Co je OpenBao a proč vznikl?
OpenBao je komunitní fork HashiCorp Vault, který v prosinci 2024 přijala Linux Foundation jako oficiální sandbox projekt pod licencí Mozilla Public License 2.0. Přímý spouštěč byl přechod HashiCorpu z MPL na Business Source License (BUSL) v srpnu 2023. Tahle licenční změna znemožnila komerčním poskytovatelům nabízet Vault jako managed službu a vytvořila regulatorní nejistotu pro banky, telekomunikační operátory a evropské veřejné instituce, kde musí být kritická infrastruktura postavená na skutečně otevřeném softwaru.
Když se na to dívám čistě jako architektka, OpenBao řeší dva odlišné problémy najednou. První je licenční: BUSL není OSI-approved, což u nás v hyperscaleru okamžitě vypadlo z výběrového řízení pro nový secrets stack. Druhý je governance. Rozhodovací proces o roadmapě je v Linux Foundation transparentní a členové (IBM, GitLab, Cognizant, SUSE) mají hlasovací práva. To znamená, že rozhodnutí o klíčových featurách (třeba nedávné přidání OIDC provider módu) nejsou závislá na jednom výrobci.
Kódová základna zůstává vysoce podobná Vaultu 1.14, což byla poslední verze pod MPL. OpenBao 2.x přidává nové funkce, ale zachovává API path stability, takže vaše aplikace, které volají /v1/secret/data/..., budou fungovat bez úprav. Pokud přemýšlíte, co se rozbije jako první při přechodu, je to enterprise-only funkce jako HSM auto-unseal (nahrazená KMS auto-unseal) nebo namespaces (v OpenBao zatím experimentální).
OpenBao vs HashiCorp Vault: srovnání pro rok 2026
Srovnání dává smysl rozdělit na dvě osy: technická kompatibilita a organizační rizika. Technicky jsou si OpenBao 2.3 a Vault 1.17 velmi blízko. Sdílejí storage formát, HCL syntax pro politiky a stejné REST API cesty. Kde se liší, je enterprise vrstva Vaultu (HSM podpora, MFA moduly, replikace mezi datovými centry, DR mode), která v OpenBao chybí nebo je nahrazená komunitními alternativami.
Kritérium
OpenBao 2.3
HashiCorp Vault 1.17
Licence
MPL 2.0 (OSI approved)
BUSL 1.1 (non-OSI) / Enterprise
Governance
Linux Foundation, multi-vendor
IBM (od 2024)
Storage backend
Integrated Raft, PostgreSQL (experimental)
Integrated Raft, Consul
Auto-unseal
AWS/GCP/Azure KMS, Transit
KMS, HSM (Enterprise), Transit
Cena produkčního nasazení
0 Kč, jen infrastruktura
Od cca 6 000 USD/uzel/rok (Enterprise)
Post-quantum kryptografie
ML-KEM v transit engine (2.3+)
Roadmap na 2026 Q4
Podpora migrace
Přímá, kompatibilní storage
N/A
Namespaces
Experimentální (2.4 roadmap)
Enterprise only
Pro střední velikost nasazení (do zhruba 200 aplikací a jedno datacentrum) je OpenBao funkčně rovnocenný. Pro globální multi-region nasazení s aktivní geo-replikací zůstává Vault Enterprise stále silnější. A upřímně, pokud potřebujete FIPS 140-3 validované HSM binding pro obranný sektor, komunitní ekvivalent zatím není.
Instalace OpenBao na Linuxu krok za krokem
Na Debianu/Ubuntu a RHEL derivátech existuje oficiální repozitář, který je maintainován komunitou Linux Foundation. Doporučuju používat repository místo tarballu, protože získáte automatické bezpečnostní aktualizace přes unattended-upgrades. Následující postup předpokládá Ubuntu 24.04 LTS nebo Rocky Linux 9.
Ve firmách, kde nesmíme používat externí APT zdroje, si stavíme vlastní balíček z GitHub release. Zdrojový tarball na openbao/openbao releases je podepsaný přes Sigstore/cosign, takže verifikace se dá zautomatizovat v CI. Threat model tady je jasný: kompromitovaná binárka OpenBao znamená kompromitovaný celý secret perimetr, takže verifikace podpisu není optional.
Pro produkci důrazně doporučuju spouštět OpenBao pod přísně omezenou hardened systemd unit s namespace izolací. Capabilities jen CAP_IPC_LOCK, PrivateTmp=yes, ProtectSystem=strict, ProtectHome=yes a ReadWritePaths=/var/lib/openbao.
Inicializace, unseal a základní konfigurace
OpenBao startuje v tzv. sealed módu. Datový storage je zašifrovaný a démon nezná master key. Unseal proces master key rekonstruuje ze Shamir shares (výchozí: 5 shares, 3 potřeba k rekonstrukci) nebo z externího KMS. Pro produkční instalaci téměř vždy volím KMS auto-unseal, protože Shamir vyžaduje 3 lidi u telefonu pokaždé, když restartuje uzel. Zažila jsem to v jedné pojišťovně, a věřte mi, na oncall smyčce po druhé půlnoční debordelizaci si tenhle luxus odpustíte.
Minimální konfigurační soubor /etc/openbao.d/openbao.hcl s Raft storage vypadá takhle:
Po startu služby inicializujte cluster. bao operator init vrací root token, který si musíte okamžitě uložit do offline trezoru a v produkci ho zrušit hned po vytvoření prvních admin politik (root token se nedá revoke-nout jinak než root generate nebo úplným restartem).
export BAO_ADDR=https://127.0.0.1:8200
bao operator init -recovery-shares=5 -recovery-threshold=3
# Výstup obsahuje 5 recovery keys a Initial Root Token. Uložte OFFLINE!
# Recovery Key 1: WQ8P...
# Initial Root Token: s.abc123...
bao status
# Sealed: false (díky auto-unseal je démon připraven)
Secrets engines: KV, dynamické databázové credentials a PKI
OpenBao rozlišuje mezi statickými a dynamickými secrets. KV v2 (versioned key-value) je nejběžnější statický engine pro API tokeny nebo konfigurační stringy. Dynamické engines generují credentials on-demand s krátkou TTL a automaticky je odvolávají. To je klíčové z hlediska threat modelu. Pokud útočník ukradne PostgreSQL heslo, které OpenBao vygeneroval 15 minut zpět, po hodině je heslo neplatné bez jakéhokoli zásahu operátora.
# 1) KV v2 pro statické secrets
bao secrets enable -path=secret kv-v2
bao kv put secret/app/prod/api-key value="pk_live_..."
# 2) Databázové dynamické credentials pro PostgreSQL
bao secrets enable database
bao write database/config/prod-app \
plugin_name=postgresql-database-plugin \
allowed_roles="readonly,readwrite" \
connection_url="postgresql://{{username}}:{{password}}@10.0.2.5:5432/app?sslmode=require" \
username="bao_admin" \
password="$ADMIN_PASSWORD"
bao write database/roles/readonly \
db_name=prod-app \
creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
default_ttl="1h" max_ttl="24h"
# Aplikace si vytáhne fresh credentials
bao read database/creds/readonly
# username: v-token-readonly-abc, password: A1B2C3..., lease_duration: 3600
PKI engine je pro mě osobně killer feature. Nahradí interní CA, integruje se s ACME a umožňuje krátkodobé certifikáty pro service mesh. Kombinaci s SSH CA jsem popsala v článku o OpenSSH 10 a certifikačních autoritách.
bao secrets enable pki
bao secrets tune -max-lease-ttl=87600h pki
bao write -field=certificate pki/root/generate/internal \
common_name="internal.example.cz" ttl=87600h > /etc/openbao.d/root-ca.crt
bao write pki/roles/service-mesh \
allowed_domains="svc.cluster.local" \
allow_subdomains=true \
max_ttl="72h"
Transit engine (encryption-as-a-service) v OpenBao 2.3 nově podporuje ML-KEM-768, což je post-kvantový KEM algoritmus standardizovaný v NIST FIPS 203. Aplikace mohou šifrovat citlivá data přes API, aniž by kdy viděly klíč. To je ideální pro GDPR pseudonymizaci telefonních čísel a rodných čísel.
Autentizace: AppRole, JWT a Kubernetes auth
Root token nikdy nedávejte aplikacím. Auth metody vytvářejí short-lived tokeny navázané na konkrétní identitu (servisní účet, GitLab pipeline, Kubernetes pod nebo GitHub Actions workflow). Nejběžnější trojlístek v produkci: AppRole pro tradiční VMs, JWT/OIDC pro CI/CD a Kubernetes auth pro pody.
# AppRole pro Linux VMs a systemd služby
bao auth enable approle
bao write auth/approle/role/prod-app \
token_ttl=1h token_max_ttl=4h \
bind_secret_id=true \
secret_id_ttl=24h \
policies="prod-app-read"
ROLE_ID=$(bao read -field=role_id auth/approle/role/prod-app/role-id)
SECRET_ID=$(bao write -f -field=secret_id auth/approle/role/prod-app/secret-id)
# Login z aplikace (přes systemd LoadCredential)
bao write auth/approle/login role_id=$ROLE_ID secret_id=$SECRET_ID
Pro GitHub Actions pipeline s OIDC federací nakonfigurujte JWT backend. Runner získá krátký OIDC token od GitHubu, ten vymění za OpenBao token. Žádné dlouhodobé secret ID v repository secrets, žádný risk exfiltrace přes malicious PR.
bao auth enable jwt
bao write auth/jwt/config \
oidc_discovery_url="https://token.actions.githubusercontent.com" \
bound_issuer="https://token.actions.githubusercontent.com"
bao write auth/jwt/role/gha-deploy \
role_type="jwt" \
user_claim="sub" \
bound_audiences="https://github.com/acme" \
bound_claims='{"repository":"acme/prod-app","ref":"refs/heads/main"}' \
policies="deploy" \
token_ttl=15m
Kubernetes auth (přes ServiceAccount JWT verifikaci) je natolik standardní, že OpenBao Helm chart ho aktivuje jedním řádkem values.yaml. Threat model: každý pod má svou identitu, žádné shared secrets, kompromitace jednoho podu neohrožuje ostatní.
Politiky, audit devices a threat model
Politiky OpenBao jsou HCL soubory popisující, jaké API cesty smí token volat s jakými metodami. Princip least privilege je zde absolutně kritický. Jednou z nejčastějších chyb v produkci je politika s path "secret/*" { capabilities = ["read"] }, která dává čtení všech secrets místo jen prod/app/*.
# prod-app-read.hcl (čtení jen svých secrets, žádné listování)
path "secret/data/app/prod/*" {
capabilities = ["read"]
}
path "database/creds/readonly" {
capabilities = ["read"]
}
# Explicitní deny (bez toho by dědění mohlo unbypass)
path "secret/data/*" {
capabilities = ["deny"]
}
bao policy write prod-app-read prod-app-read.hcl
Audit devices jsou povinné. Bez auditu nemáte forenzní stopu, kdo který secret přečetl, a to je první otázka po incidentu. OpenBao podporuje file, syslog a socket audit sink. V produkci vždy zapínám dva paralelní sinky. Pokud jeden selže (plný disk, zablokovaný socket), démon přestane odpovídat, aby nešlo secrets číst bez auditu. To je záměrné bezpečnostní chování.
bao audit enable file file_path=/var/log/openbao/audit.log
bao audit enable -path=syslog syslog tag="openbao" facility="AUTH"
Threat model, který používáme při design review: (1) kompromitace jednoho aplikačního uzlu, maximální dopad je set secrets, ke kterým měl token přístup, po dobu TTL tokenu; (2) kompromitace OpenBao démonu, auto-unseal KMS klíč zabezpečený IAM podmínkami (source IP, MFA), útočník nemůže odemknout zálohu jinde; (3) kompromitace celého clusteru, recovery klíče v offline trezoru a rotace všech dynamických credentials do 24h.
Vysoká dostupnost s Raft a auto-unseal
Integrated Raft storage odstraňuje externí závislosti. Consul, etcd nebo databázový backend nejsou potřeba. Doporučené produkční nasazení: 3 nebo 5 uzlů v jednom datacentru, každý s vlastním Raft peer ID. Kvorum je (N/2)+1, takže 3-uzlový cluster přežije výpadek jednoho uzlu, 5-uzlový cluster dvou uzlů.
# Na uzlu bao-2 se připojíte k existujícímu clusteru
bao operator raft join https://bao-1.internal:8200
bao operator raft list-peers
# Node Address State Voter
# bao-1 bao-1.internal:8201 leader true
# bao-2 bao-2.internal:8201 follower true
# bao-3 bao-3.internal:8201 follower true
# Automatické snapshoty pro DR
bao operator raft snapshot save /backup/openbao-$(date +%F).snap
Auto-unseal přes cloudové KMS znamená, že po restartu uzel sám zavolá KMS decrypt API a odemkne storage. Odpadá noční pager duty za operátory s Shamir shares. V AWS použijte AWS KMS seal s MRK (multi-region key), který funguje napříč regiony pro DR scénáře.
Integrace s Kubernetes a CI/CD pipeline
Pro Kubernetes doporučuju Vault Secrets Operator (VSO) nebo External Secrets Operator (ESO). Oba od verze 0.10 podporují OpenBao endpoint bez modifikací. VSO synchronizuje OpenBao secrets do nativních Kubernetes Secret objektů, ESO umí i další backendy (AWS Secrets Manager, GCP Secret Manager) v jednom operátoru. Pro clustery s regulatorní compliance (PCI DSS, HIPAA) upřednostňuji VSO kvůli užší integraci s auth metodami.
V CI/CD kontextu je nejčistší flow ten popsaný v sekci JWT autentizace. Pipeline si za OIDC token vyžádá krátkodobé databázové credentials, provede migraci, credentials po hodině zmizí. Statické API tokeny v secrets: sekci GitHub Actions patří do minulosti. Jsou to lákavý cíl pro supply chain útoky přes malicious PR nebo kompromitovanou dependency.
Migrace z HashiCorp Vault na OpenBao
Migrace je díky sdílenému storage formátu neobvykle přímočará. Pro Vault 1.14 (poslední MPL verze) je to prakticky drop-in replace: zastavíte Vault, nainstalujete OpenBao, restartujete. Pro Vault 1.15+ jsou nutné dva mezikroky, nejprve downgrade metadat na 1.14 formát (přes Raft snapshot a restore), pak přechod na OpenBao 2.3.
Enterprise-only funkce (namespaces, DR replication, HSM seal) je nutné migrovat manuálně. Namespaces sloučit do jedné root instance nebo rozdělit na více clusterů, HSM seal nahradit KMS auto-unseal, DR replication postavit na externí strategii (Raft snapshoty do S3 s cross-region replication). Většina týmů, se kterými jsem migraci konzultovala, vystačila s auto-unseal a snapshoty.
Často kladené otázky
Je OpenBao produkčně stabilní v roce 2026?
Ano. Verze 2.0 vyšla v prosinci 2024, aktuální 2.3.1 (červen 2026) je označená jako Long Term Support s garancí bezpečnostních patchů 24 měsíců. IBM, SUSE a GitLab ho používají v produkci a přispívají do jádra.
Jak se liší OpenBao od HashiCorp Vault z pohledu API?
REST API cesty (/v1/secret/*, /v1/auth/*) i formáty odpovědí jsou identické s Vault 1.14. Rozdíl je jen v binárce (bao vs vault) a environment proměnných (BAO_ADDR vs VAULT_ADDR). Většina SDK klientů funguje bez úprav.
Podporuje OpenBao integraci s Kubernetes?
Ano. Vault Secrets Operator i External Secrets Operator jsou od verze 0.10 kompatibilní. Kubernetes auth backend funguje totožně jako u Vaultu a Helm chart s minimální úpravou values.yaml.
Můžu migrovat z Vault Enterprise na OpenBao?
Community edition Vaultu ano, prakticky drop-in. Enterprise features jako namespaces, DR replication a HSM seal nemají v OpenBao přímý ekvivalent. Je potřeba je nahradit auto-unseal přes cloud KMS a externí backup strategií.
Jaké jsou alternativy k OpenBao pro správu secrets na Linuxu?
Pro small-scale nasazení SOPS + age (šifrování v Git), pro cloud-native prostředí AWS Secrets Manager, GCP Secret Manager nebo Azure Key Vault. Pro on-premise s auditní stopou a dynamickými credentials zůstává OpenBao (nebo Vault) nejsilnější open-source volbou.
