🔴 Advanced

HashiCorp Vault — secrets, PKI a dynamické credentials

HashiCorp Vault je centralizovaný systém na správu tajomstiev, kryptografiu a dynamickú generáciu credentials. Vznikol v roku 2015 ako odpoveď na roztrúsené správanie API kľúčov, databázových hesiel a TLS certifikátov naprieč infraštruktúrou — s cieľom poskytnúť jediné auditovateľné miesto, kde sa tajomstvá generujú, distribuujú, rotujú a ničia.

Vault sa od podobných nástrojov odlišuje jednou kľúčovou filozofiou: aplikácia by nemala vlastniť dlhodobé statické credentials. Namiesto toho dostane krátkodobé dynamické credentials s automatickým expiráciou — a v prípade kompromitácie sa škoda obmedzí na okno platnosti tokenu.

Kontext: BSL relicensing, IBM a OpenBao

V auguste 2023 HashiCorp zmenil licenciu všetkých svojich produktov — vrátane Vault — z Mozilla Public License 2.0 (MPL 2.0) na Business Source License 1.1 (BSL). BSL nie je OSI-schválená open-source licencia: zakazuje používanie softvéru v komerčných produktoch, ktoré priamo konkurujú HashiCorpu. Pre väčšinu interných produkčných nasadení to prakticky nič nezmenilo, no komunita na zmenu reagovala rýchlo.

V januári 2024 vznikol pod záštitou Linux Foundation projekt OpenBao — komunitný fork Vault z posledného MPL-licencovaného commitu. IBM inžinieri boli medzi prvými prispievateľmi, čo nesie istú iróniu — v apríli 2024 IBM oznámil akvizíciu HashiCorpu za 6,4 miliardy USD, ktorá bola dokončená v februári 2025 po schválení FTC a britského CMA. HashiCorp dnes funguje ako súčasť IBM, pričom Vault zostáva pod BSL.

OpenBao medzitým rastie. V marci 2026 vyšla verzia 2.5.2, projekt má viac ako 100 prispievateľov a plnú MPL 2.0 licenciu. Pre produkčné nasadenia, kde BSL vyvoláva právnu neistotu, je OpenBao dnes reálnou drop-in alternatívou — API, CLI aj konfiguračný formát sú identické s Vault 1.x.

Vault samotný v roku 2026 prešiel z poslednej minor verzie 1.20 rovno na 2.0 (HashiCorp/IBM zámerne signalizovali väčšiu zmenu API a tooling layeru, nie len ďalší minor bump). 2.0 prináša SCIM identity provisioning, Secret Sync cez workload identity federation a engine pre rotáciu lokálnych Linux účtov.

Storage backends

Vault ukladá všetky svoje dáta (šifrované) do nakonfigurovaného storage backendu. Výber backendu je zároveň výber HA stratégie.

Integrated Storage — Raft (odporúčané)

Od verzie 1.4 je Raft vstavaným distributed consensus enginom Vault. Netreba externý Consul klaster, nie sú žiadne ďalšie pohyblivé časti — Vault uzly sami tvoria Raft cluster s leader voľbou.

# vault.hcl — Raft storage
storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-node-1"

  retry_join {
    leader_api_addr = "https://vault-node-2:8200"
  }
  retry_join {
    leader_api_addr = "https://vault-node-3:8200"
  }
}

Pre produkciu sa odporúča klaster 3 alebo 5 uzlov (quorum = n/2 + 1). Päťuzlový klaster znáša výpadok dvoch uzlov súčasne.

Consul backend (legacy)

Pôvodný odporúčaný backend pred Raft integráciou. Stále funkčný, no pre nové nasadenia ho HashiCorp aj komunita odrádzajú — Consul je dodatočná závislost s vlastným operačným bremenom.

Externé backendy (S3, PostgreSQL)

Vault podporuje aj S3-kompatibilné úložiská a PostgreSQL ako storage backend — vhodné pre jednoduché nasadenia bez požiadavky na HA. Upozornenie: S3 backend nepodporuje HA Vault cluster (viacero Vault serverov nemôže bezpečne súčasne zapisovať).

Seal / Unseal flow

Po každom štarte je Vault v stave sealed — šifrovacie kľúče sú rozdelené a dáta sú neprístupné. Vault musí byť odomknutý (unsealed) predtým, ako začne obsluhovať požiadavky.

Shamir's Secret Sharing (default)

Pri inicializácii Vault vygeneruje master key a rozdelí ho na N shares s prahom K (typicky 5 shares, threshold 3):

vault operator init -key-shares=5 -key-threshold=3

# Vault vypíše 5 unseal kľúčov a root token
# Každý kľúč treba uložiť oddelene (rôzni administrátori, offline médiá)

# Unseal — treba opakovať na každom uzle s K rôznymi kľúčmi
vault operator unseal <unseal-key-1>
vault operator unseal <unseal-key-2>
vault operator unseal <unseal-key-3>

Po reštarte uzla treba unseal zopakovať — Vault nikdy neukladá zostavený master key do pamäte pri vypnutí. Toto je kritické gotcha pre produkciu: bez auto-unseal znamená každý reštart manuálny zásah.

Auto-unseal cez cloud KMS

Pre produkčné prostredia je auto-unseal takmer povinný. Vault zašifruje master key pomocou externého KMS a pri štarte si ho sám dešifruje:

# AWS KMS auto-unseal
seal "awskms" {
  region     = "eu-central-1"
  kms_key_id = "alias/vault-unseal-key"
}

# GCP KMS
seal "gcpckms" {
  project    = "my-project"
  region     = "europe-west1"
  key_ring   = "vault-keyring"
  crypto_key = "vault-unseal"
}

# Azure Key Vault
seal "azurekeyvault" {
  tenant_id      = "..."
  client_id      = "..."
  client_secret  = "..."
  vault_name     = "myvault"
  key_name       = "vault-unseal"
}

Transit auto-unseal

Alternatíva bez cloud dependency: jeden Vault klaster unseals druhý cez Transit secrets engine. Vhodné pre air-gapped prostredia alebo multi-datacenter setups.

Auth methods

Vault neposkytuje vlastný user management — namiesto toho deleguje autentifikáciu na existujúce identity systémy cez auth methods.

Token

Najnižší level — každý prístup k Vault je nakoniec vykonaný s tokenom. Tokeny môžu byť service (dlhodobé, obnovovateľné) alebo batch (stateless, krátkodobé, vhodné pre vysokothroughputové scenáre).

AppRole (stroje)

Klasický machine-to-machine auth. Aplikácia dostane role_id (verejné, môže byť v kóde) a secret_id (tajné, injektované pri deployi):

vault auth enable approle
vault write auth/approle/role/myapp \
  token_policies="myapp-policy" \
  token_ttl=1h \
  token_max_ttl=4h \
  secret_id_ttl=24h

# Získanie role_id a secret_id
vault read auth/approle/role/myapp/role-id
vault write -f auth/approle/role/myapp/secret-id

# Login
vault write auth/approle/login role_id=... secret_id=...

Kubernetes

Pre workloady bežiace v Kubernetes klastri: pod prezentuje svoj service account JWT token, Vault ho overí voči Kubernetes TokenReview API.

vault auth enable kubernetes
vault write auth/kubernetes/config \
  kubernetes_host="https://kubernetes.default.svc" \
  kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

vault write auth/kubernetes/role/myapp \
  bound_service_account_names=myapp-sa \
  bound_service_account_namespaces=production \
  policies=myapp-policy \
  ttl=1h

JWT / OIDC (ľudia)

Pre interaktívne prihlásenie vývojárov cez SSO (Okta, Auth0, Keycloak, GitHub). Vault funguje ako OIDC relying party a vydá token na základe claims z identity providera.

AWS IAM, TLS certifikáty, LDAP

AWS IAM auth overuje identitu cez podpísaný sts:GetCallerIdentity request — ideálne pre EC2 instance alebo Lambda funkcie bez uchovávania credentials. TLS cert auth využíva klientský certifikát ako identitu. LDAP/Active Directory auth je vhodný pre existujúce enterprise directory.

Secrets engines — deep dive

KV v2 — verzionované statické secrets

vault secrets enable -path=secret kv-v2

# Zápis
vault kv put secret/myapp/db \
  password="S3cur3P@ss!" \
  username="appuser"

# Čítanie
vault kv get secret/myapp/db

# Čítanie konkrétnej verzie
vault kv get -version=3 secret/myapp/db

# História verzií
vault kv metadata get secret/myapp/db

# Soft-delete verzie
vault kv delete -versions=1,2 secret/myapp/db

KV v2 zachováva posledných N verzií (konfigurovateľné). Každý zápis vytvorí novú verziu — nikdy neprepíše existujúcu. Metadata (čas vytvorenia, zmazania, custom labely) sú prístupné oddelene od samotných dát.

Database — dynamické credentials

Toto je jeden z najsilnejších features Vault. Namiesto zdieľaného statického hesla dostane každá aplikácia (alebo každý request) jedinečné credentials s obmedzenou platnosťou:

vault secrets enable database

vault write database/config/prod-postgres \
  plugin_name=postgresql-database-plugin \
  connection_url="postgresql://{{username}}:{{password}}@db.prod:5432/appdb?sslmode=verify-full" \
  allowed_roles="app-readonly,app-readwrite" \
  username="vault-admin" \
  password="VaultAdminPass"

vault write database/roles/app-readonly \
  db_name=prod-postgres \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN ENCRYPTED PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  revocation_statements="DROP ROLE IF EXISTS \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="24h"

# Aplikácia si vyžiada credentials
vault read database/creds/app-readonly
# Key                Value
# ---                -----
# lease_id           database/creds/app-readonly/7abc...
# lease_duration     1h
# username           v-approle-app-readon-AbcDef123-1714000000
# password           A1b2-C3d4-E5f6

Po uplynutí TTL Vault automaticky revokuje role v databáze. Ak je kompromitovaný jeden token, útočník má prístup iba na dobu platnosti lease.

PKI — interná CA a krátkodobé certifikáty

Vault PKI engine funguje ako plnohodnotná certificate authority. Krátkodobé certifikáty (hodiny, nie roky) eliminujú potrebu CRL — certifikát jednoducho expiruje skôr, ako by ho bolo potrebné revokovať.

vault secrets enable pki
vault secrets tune -max-lease-ttl=87600h pki  # 10 rokov pre root CA

# Root CA
vault write pki/root/generate/internal \
  common_name="My Root CA" \
  ttl=87600h

# Intermediate CA
vault secrets enable -path=pki_int pki
vault write -format=json pki_int/intermediate/generate/internal \
  common_name="My Intermediate CA" | jq -r '.data.csr' > int.csr

vault write -format=json pki/root/sign-intermediate \
  csr=@int.csr format=pem_bundle | jq -r '.data.certificate' > int.pem

vault write pki_int/intermediate/set-signed certificate=@int.pem

# Rola pre vydávanie certifikátov
vault write pki_int/roles/web-server \
  allowed_domains="internal.example.com" \
  allow_subdomains=true \
  max_ttl=72h

# Vydanie certifikátu
vault write pki_int/issue/web-server \
  common_name="api.internal.example.com" \
  ttl=24h

Pre service mesh (mTLS) sú 1-24h certifikáty štandard — cert-manager s Vault issuerom alebo Vault Agent ich automaticky obnovujú.

Transit — Encryption-as-a-Service

Transit engine šifruje a dešifruje dáta bez toho, aby aplikácia alebo Vault klient niekedy videl raw šifrovací kľúč. Kľúč žije iba vo Vault, aplikácia posiela plaintext a dostáva ciphertext späť:

vault secrets enable transit

vault write -f transit/keys/myapp-data \
  type=aes256-gcm96

# Šifrovanie
vault write transit/encrypt/myapp-data \
  plaintext=$(echo -n "citlivé dáta" | base64)
# → ciphertext: vault:v1:abc123...

# Dešifrovanie
vault write transit/decrypt/myapp-data \
  ciphertext="vault:v1:abc123..." | base64 -d

# Rotácia kľúča (staré ciphertexty zostávajú dešifrovateľné)
vault write -f transit/keys/myapp-data/rotate

# Rewrap — prešifruje existujúci ciphertext novým kľúčom
vault write transit/rewrap/myapp-data \
  ciphertext="vault:v1:abc123..."

Transit podporuje aj HMAC, digitálne podpisy, generovanie náhodných bajtov a deriváciu kľúčov.

SSH — CA pre SSH prístup

Namiesto distribúcie verejných kľúčov cez authorized_keys Vault podpíše SSH kľúč používateľa na obmedzený čas. SSH server dôveruje Vault CA:

vault secrets enable ssh

vault write ssh/roles/ops-role \
  key_type=ca \
  allow_user_certificates=true \
  allowed_users="ubuntu,ec2-user" \
  ttl=30m \
  extensions='{"permit-pty":""}'

# Používateľ si podpíše svoj verejný kľúč
vault write ssh/sign/ops-role \
  public_key=@~/.ssh/id_ed25519.pub \
  valid_principals=ubuntu

# Výsledný podpísaný certifikát platí 30 minút
# Na SSH server: TrustedUserCAKeys /etc/ssh/vault_ca.pub

AWS — dynamické IAM credentials

vault secrets enable aws

vault write aws/config/root \
  access_key=AKIA... \
  secret_key=... \
  region=eu-central-1

vault write aws/roles/s3-reader \
  credential_type=iam_user \
  policy_document='{
    "Version":"2012-10-17",
    "Statement":[{"Effect":"Allow","Action":["s3:GetObject"],"Resource":"arn:aws:s3:::my-bucket/*"}]
  }'

vault read aws/creds/s3-reader
# → access_key, secret_key, security_token — expirujú podľa TTL

Policies — HCL, capabilities, path-based ACL

Vault policy je zoznam path-based pravidiel v HCL syntaxi. Každý token musí mať priradené policies — bez policy nemá prístup k ničomu (deny by default):

# myapp-policy.hcl

# Čítanie statických secrets aplikácie
path "secret/data/myapp/*" {
  capabilities = ["read", "list"]
}

# Zákaz admin subpriečinka
path "secret/data/myapp/admin/*" {
  capabilities = ["deny"]
}

# Dynamické DB credentials
path "database/creds/app-readonly" {
  capabilities = ["read"]
}

# Podpísanie SSH kľúča
path "ssh/sign/ops-role" {
  capabilities = ["create", "update"]
  allowed_parameters = {
    "valid_principals" = ["ubuntu"]
  }
}

# Transit šifrovanie (iba encrypt, nie decrypt)
path "transit/encrypt/myapp-data" {
  capabilities = ["create", "update"]
}

# Self-renewal tokenu
path "auth/token/renew-self" {
  capabilities = ["update"]
}

vault policy write myapp-policy myapp-policy.hcl
vault policy list
vault policy read myapp-policy

Capabilities: create, read, update, delete, list, patch, sudo, deny. deny má vždy prednosť pred ostatnými capabilities, aj ak iná policy na rovnakú cestu dáva prístup.

Vault Enterprise pridáva Sentinel — policy framework s conditions, time-based access, MFA enforcement a ďalšími pokročilými pravidlami.

Vault Agent — auto-auth a template renderer

Vault Agent je sidecar proces, ktorý rieši dva problémy: autentifikáciu a renderovanie secrets do súborov/env premenných bez zásahu aplikácie.

# vault-agent.hcl
vault {
  address = "https://vault.example.com:8200"
}

auto_auth {
  method "kubernetes" {
    mount_path = "auth/kubernetes"
    config = {
      role = "myapp"
    }
  }

  sink "file" {
    config = {
      path = "/vault/token"
    }
  }
}

template {
  source      = "/vault/templates/db.ctmpl"
  destination = "/secrets/db.env"
  perms       = "0640"
  command     = "pkill -HUP myapp"  # Signál pri zmene
}

Template súbor (db.ctmpl) používa Consul Template syntax:

{{- with secret "database/creds/app-readonly" -}}
DB_USERNAME={{ .Data.username }}
DB_PASSWORD={{ .Data.password }}
{{- end }}

Po spustení Vault Agent:

Autentifikuje sa cez Kubernetes JWT
Získa token a uloží ho do /vault/token
Vyrendruje template do /secrets/db.env
Sleduje expiráciu lease a pri blížiacej sa expirácii znovu zavolá database/creds/app-readonly, aktualizuje súbor a pošle SIGHUP aplikácii

Kubernetes integrácia

Vault Secrets Operator (VSO) — odporúčané dnes

VSO je Kubernetes operator, ktorý mapuje Vault secrets na natívne Kubernetes Secrets cez CRD. Pre GitOps workflowy je to preferovaný prístup — deklaratívny, bez sidecarov v pode.

# VaultStaticSecret — mapovanie KV v2 na Kubernetes Secret
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultStaticSecret
metadata:
  name: myapp-db-secret
  namespace: production
spec:
  type: kv-v2
  mount: secret
  path: myapp/db
  destination:
    name: myapp-db-credentials   # Kubernetes Secret názov
    create: true
    type: Opaque
  refreshAfter: 30s
  vaultAuthRef: myapp-vault-auth
---
# VaultAuth — definuje ako sa VSO autentifikuje
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultAuth
metadata:
  name: myapp-vault-auth
  namespace: production
spec:
  method: kubernetes
  mount: kubernetes
  kubernetes:
    role: myapp
    serviceAccount: myapp-sa

VSO podporuje KV v1/v2, PKI certifikáty, dynamické secrets (database, AWS) cez VaultDynamicSecret CRD a automaticky rotuje Kubernetes Secret pri blížiacej sa expirácii lease.

Injector sidecar (legacy)

Pôvodný prístup: mutating webhook injektuje vault-agent-init a vault-agent kontajnery do podu na základe anotácií. Stále funkčný, ale sidecar pattern pridáva réžiu a VSO je dnes preferovaný.

External Secrets Operator (ESO)

Ak chcete vendor-neutrálny prístup, ktorý zvládne Vault aj AWS Secrets Manager aj GCP Secret Manager z jedného operatora, ESO je rozumná voľba. Pre Vault-only prostredia je VSO vhodnejší — je udržovaný priamo HashiCorpom/IBM a má hlbšiu integráciu (dynamic secrets, lease management).

Produkčné nasadenie

3-5 node Raft HA klaster

vault-1 (leader)   vault-2 (standby)   vault-3 (standby)
     \                   |                   /
      \___________________|__________________/
                    Raft quorum
                         |
                   Load Balancer
                    (TCP L4, port 8200)

Dôležité: load balancer musí posielať všetky requests na leader (alebo mať sticky sessions). Standby uzly preposielajú write requesty na leader — read requesty môžu obsluhovať priamo ak je povolený performance_standby (Enterprise feature).

Prometheus telemetria

Vault exponuje /v1/sys/metrics?format=prometheus endpoint:

telemetry {
  prometheus_retention_time = "30s"
  disable_hostname           = true
}

Kľúčové metriky: vault_core_unsealed, vault_token_count, vault_lease_count, vault_audit_log_response_failure, vault_secret_kv_count.

DR replication (Enterprise)

Pre multi-datacenter DR bez Enterprise je jedinou možnosťou pravidelný backup Raft snapshotu:

# Snapshot Raft stavu
vault operator raft snapshot save vault-backup-$(date +%Y%m%d).snap

# Obnovenie
vault operator raft snapshot restore vault-backup-20260422.snap

Snapshot obsahuje všetky šifrované dáta — bez pôvodných unseal kľúčov (alebo KMS prístupu) je nepoužiteľný.

Audit logs

Každý request a response prechádza cez audit backend pred odoslaním odpovede klientovi. Ak nie je dostupný žiadny audit backend, Vault odmietne request — toto je zámerné a nemá sa obchádzať.

# File audit
vault audit enable file file_path=/var/log/vault/audit.log

# Syslog
vault audit enable syslog tag="vault" facility="AUTH"

# Socket (napr. pre Loki alebo FluentD)
vault audit enable socket address="127.0.0.1:9090" socket_type=tcp

Audit záznamy sú vo formáte JSON. Hodnoty (passwords, tokens, credentials) sú HMAC-ované SHA-256 so salt — nie sú v plaintext, ale sú deterministicky porovnateľné (ak viem hodnotu, môžem overiť, že daný záznam ju obsahoval).

{
  "time": "2026-04-22T10:00:00Z",
  "type": "response",
  "auth": {
    "accessor": "auth_approle_abc123",
    "policies": ["myapp-policy"],
    "token_type": "service"
  },
  "request": {
    "operation": "read",
    "path": "secret/data/myapp/db",
    "namespace": {"id": "root"}
  },
  "response": {
    "data": {
      "password": "hmac-sha256:abc...",
      "username": "hmac-sha256:def..."
    }
  }
}

Pitfalls a gotchas

Token leasing a renewal — najčastejšia chyba

Každý token a každý dynamický secret má lease s TTL. Aplikácia musí aktívne obnovovať token pred expiráciou, inak jej prístup zanikne. Vault Agent toto rieši automaticky — bez neho treba implementovať renewal loop v aplikácii.

Bežná chyba: aplikácia raz získa token pri štarte, uloží ho staticky a po 24 hodinách (alebo max_ttl) začne dostávať 403. TTL tokenu treba monitorovať a pri blížiacej sa expirácii ho obnovovať volaním vault token renew.

Sealed at restart = downtime

Bez auto-unseal každý reštart Vault uzla vyžaduje manuálny unseal s K administrátormi s unseal kľúčmi. Pre produkciu je auto-unseal (cloud KMS alebo Transit) takmer nevyhnutný.

Backup Raft stavu

Snapshot Raft stavu treba zálohovať pravidelne. Po obnovení zo snapshotu Vault stále potrebuje unseal — kľúče nie sú súčasťou snapshotu. Záloha snapshotu bez zálohy unseal kľúčov (alebo KMS prístupu) je nepoužiteľná.

Root token v produkcii — nikdy

Root token vydaný pri vault operator init má neobmedzené oprávnenia a nepodlieha auditovaniu policies. Po inicializácii treba root token zrevokovať:

vault token revoke <root-token>

# Ak treba obnoviť root token (emergency)
vault operator generate-root -init
# Vyžaduje unseal kľúče (quorum)

Lease explosion pri dynamic credentials

Každý vault read database/creds/... vytvorí nový lease. Ak aplikácia pri každom requeste vyžaduje nové credentials namiesto opakovania tých existujúcich, Vault databáza sa zaplní expirujúcimi lease záznamy a databáza bude mať stovky zbytočných user rolí. Riešenie: credentials cachovať v aplikácii po dobu ich TTL, nie žiadať nové pri každom requeste.

Alternatívy v roku 2026

Nástroj	Typ	Dynamické credentials	Open-source	Vhodné pre
OpenBao	Self-hosted server	Áno (plné)	MPL 2.0	Drop-in náhrada Vault bez BSL
AWS Secrets Manager	Managed SaaS	Cez Lambda rotáciu	Nie	Čisto AWS infraštruktúra
GCP Secret Manager	Managed SaaS	Nie	Nie	Čisto GCP infraštruktúra
Azure Key Vault	Managed SaaS	Čiastočne	Nie	Čisto Azure infraštruktúra
Infisical	Self-hosted / SaaS	Nie (statické)	Áno (EE BUSL)	Menšie tímy, developer-friendly UI
Doppler	SaaS	Nie	Nie	Rýchly štart, malé tímy

OpenBao je dnes najdôležitejšia alternatíva pre tých, ktorých trápi BSL alebo IBM vlastníctvo — API je identické s Vault, migrácia je otázka zmeny endpointu a certifikátov. OpenBao aktívne pridáva features (namespaces, horizontálna read-škálovateľnosť), ktoré predtým boli Enterprise-only v Vault.

Cloud-natívne riešenia (AWS/GCP/Azure Secrets Manager) sú ideálne ak ste vendor-locked do jedného cloudu a nepotrebujete dynamické database credentials ani PKI engine. Sú jednoduchšie na prevádzku, ale nemajú Vault-ekvivalentné features.

Infisical a Doppler sú developer-friendly SaaS riešenia pre tímy, kde hlavnou požiadavkou je jednoduchý centralizovaný secrets store pre 12-factor aplikácie — nie pokročilá PKI alebo dynamické cloud credentials.

Pre enterprise multi-cloud prostredie s požiadavkou na dynamické credentials, PKI, SSH CA a silný audit trail zostáva Vault (alebo OpenBao) bez konkurencie.

Zhrnutie

Vault rieši problém, ktorý ostatné nástroje len čiastočne adresujú: centralizovaný životný cyklus secrets s dynamickou generáciou, automatickou rotáciou a kompletným audit trailom. Nie je to jednoduchý nástroj — Raft HA, auto-unseal, policy design, lease management a integrácia s Kubernetes VSO vyžadujú čas na zvládnutie.

Odporúčaný produkčný setup v roku 2026: 3-uzlový Raft klaster s cloud KMS auto-unseal, Vault Secrets Operator pre Kubernetes workloady, AppRole alebo Kubernetes auth pre stroje, OIDC pre ľudí, audit log do centralizovaného log systému a pravidelné Raft snapshoty. Root token zrevokovať ihneď po inicializácii.

Pre nové projekty s právnymi otáznikmi nad BSL: OpenBao 2.5 je drop-in náhrada s aktívnou komunitou a plnou open-source licenciou.