Skip to content

Vault

Summary

HashiCorp Vault is an identity-based secrets and encryption management system: dynamic secrets, encryption as a service (Transit), PKI, and centralized policy and audit. It is owned by IBM since HashiCorp's acquisition closed on 2025-02-27 and has been source-available under BSL 1.1 since Vault 1.15. The current line is Vault 2.1 (2.1.1, 2026-09-16). The 2.0 jump in April 2026 moved Vault Enterprise to the IBM Support Cycle-2 lifecycle. The MPL-licensed community fork is OpenBao, an OpenSSF sandbox project.

Overview

Vault is the most feature-rich general-purpose secrets manager. Applications and people authenticate through an auth method (Kubernetes, OIDC, AppRole, cloud IAM, LDAP), receive a token with policies, and use it to read static secrets, request short-lived dynamic credentials, or ask Vault to encrypt and sign data. Every request is audited. It runs self-managed (Community or Enterprise) or managed as HCP Vault Dedicated, across multi-cloud, hybrid, and Kubernetes environments.

Key Facts

Attribute Detail
Website vaultproject.io
Latest Version 2.1.1 (2026-09-16); 2.1.0 GA 2026-09-01; 2.0.0 GA 2026-04-14
Previous lines 1.21.x and 1.20.x now Enterprise-only patches; 1.19.x is LTS to Apr 2027
Language Go (2.1.1 built with Go 1.26.8)
License BSL 1.1 for 1.15.0 and later (each release converts to MPL 2.0 after four years); Enterprise is commercial
Owner IBM (HashiCorp acquisition closed 2025-02-27)
Support model Enterprise 2.x: IBM Support Cycle-2 (2 years base + 1 extended + 3 sustained). CE: patches only on the newest line
Managed offering HCP Vault Dedicated (Development, Essentials, Standard tiers); HCP Vault Secrets retired (EOL by 2026-07-01)
Stars ~31k+ (recorded by 2026-08)
Open-source fork OpenBao 2.7.0 (2026-09-23), MPL 2.0, Linux Foundation / OpenSSF

Architecture at a Glance

Clients authenticate through an auth method, get a token, and every read or write passes through the policy check, the audit broker, and the encryption barrier before reaching storage.

flowchart LR
    APP["App, Vault Agent, VSO"] -->|"login"| AUTH["Auth methods<br/>(kubernetes, oidc, approle)"]
    AUTH -->|"token + policies"| APP
    APP -->|"request with token"| CORE["Vault core<br/>ACL + audit broker"]
    CORE --> SE["Secrets engines<br/>(kv, database, pki, transit)"]
    SE --> BARRIER["Encryption barrier"]
    BARRIER -->|"ciphertext"| RAFT["Integrated Storage (Raft)"]
    KMS["Cloud KMS / HSM seal"] -->|"auto-unseal"| BARRIER

    style BARRIER fill:#f9a825,color:#000

Details: component architecture, seal and unseal, storage and HA.

Key Features

Feature Detail
Dynamic secrets Short-lived, auto-revoked database, cloud, SSH, and Kubernetes credentials
Transit Encrypt, decrypt, sign, and envelope encryption without exposing keys
PKI Root and intermediate CAs, ACME, EST/SCEP/CMPv2 (Enterprise), public CA integration (2.0, Enterprise)
KV v2 Versioned key-value storage with check-and-set
Identity-based access Entities, groups, templated ACL policies, OIDC provider
Kubernetes integration Kubernetes auth, Agent injector, CSI provider, Vault Secrets Operator
Enterprise Namespaces, DR and performance replication, performance standbys, Sentinel, control groups, HSM, secrets sync, SCIM, Agentic IAM for AI agents (GA in 2.1)

The full tables of auth methods, engines, seals, and editions are in Reference.

Recent Developments

  • Vault 2.1.0 (2026-09-01): Agentic IAM (agent registry, OAuth resource server, Rich Authorization Requests) is GA for Enterprise; PKI adds PKCS#12/JKS bundles and DNS-01 automation for external CAs; SLH-DSA hybrid signatures in Transit (Enterprise).
  • Vault 2.0.x (April to August 2026): first major version since 1.0. Adds SCIM provisioning, SPIFFE JWT-SVIDs, workload identity federation for secrets sync, Transit envelope encryption, a local accounts engine, and IBM Passport Advantage licensing. Breaking changes include authenticated sys/rekey and sys/generate-root, rejection of uncleaned paths, an 8 KB token header limit, and removal of IPC_LOCK from official containers (2.0.2).
  • Vault 1.21 (2025-10-22): experimental post-quantum ML-DSA and SLH-DSA signatures in Transit, SPIFFE auth (Enterprise), secret recovery from snapshots (Enterprise).
  • Vault 1.20 (2025-06-25): disable_mlock must be set explicitly with Integrated Storage; PKI SCEP (Enterprise).
  • HCP: HCP Vault Secrets reached end of sale on 2025-06-30 and end of life by 2026-07-01; HCP Vault Dedicated Starter clusters ended on 2025-08-15.

Evaluation

Pros Cons
Dynamic secrets are the standout feature BSL 1.1 is not an OSI open-source license
Encryption as a service (Transit) and a full PKI Complex to operate (unseal, Raft quorum, upgrades, audit)
Wide auth and engine plugin catalogue Heavy for teams that only need static secrets
Strong audit model; default-deny policies Namespaces, replication, read scaling, and Sentinel need Enterprise
Integrated Storage removes the Consul dependency CE gets patches only on the newest line
Large ecosystem: Terraform provider, VSO, ESO, CSI Per-client pricing on Enterprise and HCP; OpenBao fork splits the community

When It Fits

  • Good fit: multi-cloud or hybrid estates that need dynamic database or cloud credentials, an internal PKI, or application-level encryption with central audit.
  • Consider alternatives: a single-cloud team with only static secrets (a cloud secret manager plus ESO is simpler), or a strict OSI-license requirement (OpenBao).

Alternatives

Alternative Relationship to Vault
OpenBao MPL 2.0 fork of the last MPL Vault code; API-compatible core, bao CLI, namespaces without an Enterprise license; no DR/performance replication
AWS Secrets Manager, GCP Secret Manager, Azure Key Vault Managed, single-cloud stores; less dynamic-secret coverage
External Secrets Operator Complements Vault: syncs secrets from Vault or cloud stores into Kubernetes Secrets
SOPS Encrypts files in Git; complements Vault for GitOps

See the domain comparison: Secrets Management Comparison.

Topic Map

  • How-to Guides: install, production cluster, init and unseal, audit, commands and recipes, backup, Consul-to-Raft migration, upgrade to 2.x, monitoring, troubleshooting.
  • Reference: release and support matrix, editions and HCP tiers, auth methods, secrets engines, storage, seals, tokens, config parameters, ports, metrics, sizing, hardening checklist, Vault vs OpenBao.
  • Explanation: architecture, barrier and key hierarchy, Raft and HA, mlock trade-off, auth and tokens, leases, policies, replication, security model, licensing and the OpenBao fork.

Sources

Questions

Answered

  • Q: Can Vault auto-unseal? Yes. Community Edition supports AWS KMS, GCP Cloud KMS, Azure Key Vault, OCI KMS, AliCloud KMS, and the Transit engine of another Vault cluster. PKCS#11 HSM auto-unseal and Seal HA need Enterprise. Auto-unseal removes the need to enter Shamir shares after every restart; the init step then returns recovery keys.

  • Q: What is the difference between KV v1 and KV v2? KV v1 is a simple store without versions. KV v2 keeps versions (10 by default), supports check-and-set writes, and has a metadata endpoint. Its API paths use data/ and metadata/ under the mount, which matters when writing policies.

  • Q: What happens when a Vault node fails in a Raft cluster? If a standby fails, the cluster keeps working. If the active node (Raft leader) fails, the remaining voters elect a new leader if they have quorum, and that node becomes active. The failed node rejoins as a follower. In Community Edition, standbys forward client requests to the active node, so losing a standby does not reduce read capacity; Enterprise performance standbys do serve reads.

  • Q: How does Vault handle secret rotation? Dynamic secrets (Database, AWS, PKI) are new per request and revoked at lease end. Database static roles and the Enterprise rotation manager rotate existing accounts on a schedule. KV values are not rotated by Vault; external automation must update them and restart consumers.

  • Q: What is the Transit engine used for? Encryption as a service. Applications send plaintext and get ciphertext (or signatures, HMACs, data keys); keys stay in Vault unless created exportable. It supports key versioning and rewrap, convergent encryption, derived keys, and since 2.0 envelope encryption.

  • Q: What is the difference between DR and Performance replication? DR replication copies everything, including tokens and leases, to a secondary that serves no clients until promoted. Performance replication copies configuration and secrets but not tokens or leases; secondaries serve reads locally, issue their own tokens, and forward writes to the primary. Both are Enterprise features.

  • Q: How does Vault integrate with Kubernetes without Vault Agent? Pods can call the Kubernetes auth method directly with their ServiceAccount JWT. Vault Secrets Operator (VSO) syncs Vault secrets into Kubernetes Secrets, the CSI provider mounts them as volumes, and External Secrets Operator is a third-party alternative. None of these need application code changes.

  • Q: What are the operational considerations when migrating from Consul to Integrated Storage? Use vault operator migrate while Vault is stopped (offline), then start and unseal the new Raft node and join the others. Plan disk for Raft data and snapshots, set disable_mlock, and test the restore of a snapshot. See How-to Guides.

  • Q: Why did Vault jump from 1.21 to 2.0? The 2.0 release (2026-04-14) aligned Vault with IBM versioning and the IBM Support Cycle-2 lifecycle. It does include breaking changes, listed in How-to Guides.

Open

  • Will IBM keep the BSL 1.1 terms for Vault Community Edition, or change licensing again as it did with the Vault Platform and Agentic IAM licensing terms in 2.1.0?
  • How far will OpenBao and Vault APIs diverge now that OpenBao ships features (control groups, external keys, PebbleDB) that Vault does not have in CE?
  • Will HashiCorp publish controlled performance benchmarks for Vault 2.x Integrated Storage? None are published as of 2026-09-28.