Split View: OpenBao는 Vault에서 실제로 얼마나 갈라졌나 — v2.6 네임스페이스 봉인까지, 릴리스 노트로 확인한 분기점

How Far Has OpenBao Actually Diverged from Vault — Tracing the Fork Through Release Notes, Up to v2.6's Namespace Sealing

• Introduction — Two Years Post-Fork, Release Notes Instead of Feelings
• Background — Where It Split, and How Ownership Moved
• Divergence by Version — What OpenBao Added
• Namespaces — The Moment an Enterprise Feature Crossed Over, and Beyond
• The Opposite Direction — What OpenBao Is Removing
• Moving in the Same Direction — Security Defaults and CVE Porting
• What You're On the Hook For on the Vault Side — The CE Patch Cliff
• So, What Should You Pick
• Closing
• References

Introduction — Two Years Post-Fork, Release Notes Instead of Feelings

Today (2026-07-17) is exactly two years since OpenBao v2.0.0 GA, and it's been three days since v2.6.0 shipped. And the topic still splits into camps — one side says "the BUSL switch was a betrayal," the other says "the fork can't keep up on features or support." The background of the license switch itself was covered in Open Source Licensing 2026 — BSL, SSPL, FSL, and 8 Years of Rebellion Against the Cloud — A Deep Dive (2026), so this post answers a different question. Where did the fork actually diverge — not marketing copy, but only what's confirmed in the release notes, changelogs, and commits each project has published itself.

The story of OpenTofu — a fork from the same family — starting to ship features upstream Terraform doesn't have was covered in OpenTofu's dynamic lifecycle. This post is the secrets-management version of that story.

Background — Where It Split, and How Ownership Moved

Laid out in chronological order, here's what's confirmed.

• The Vault repo's LICENSE file is BUSL 1.1, and it specifies the change applies to "Vault Version 1.15.0 or later." That means the 1.14 series is the last MPL codebase.
• OpenBao split off at that point. The v2.0.0 release notes state flatly that "OpenBao is fully API compatible with Vault 1.14.9," and note that Enterprise features are not supported. GA was 2024-07-17, and at that point even the web UI was missing.
• IBM's acquisition of HashiCorp closed on 2025-02-27 (per the IBM newsroom).
• OpenBao moved from LF Edge to an OpenSSF sandbox project on 2025-06-17.
• On 2026-03-26, the licensor in the Vault repo's LICENSE changed from "HashiCorp, Inc." to "International Business Machines Corporation (IBM)" (visible directly in the commit diff — the competing-product clause's protected subject also changed to "IBM Corp's paid version(s)").
• On 2026-04-14, Vault 2.0.0 shipped. It's the first major version jump since 1.0 (2018), and the FEATURES list includes "IBM PAO License Integration" — a feature that lets Vault Enterprise be used with an IBM license key.

Post-acquisition integration has trickled all the way down into the license file and the feature list. Now let's look at what the fork side has been building.

Divergence by Version — What OpenBao Added

Everything below is confirmed from the OpenBao CHANGELOG and GitHub releases. Dates are release-publish timestamps per the GitHub API.

v2.1.0  2024-11-29  Transactional storage(GH-292), mount table size limit removed(GH-622),
                    PostgreSQL backend revived + paginated LIST(GH-467)
v2.2.0  2025-03-05  PKCS#11 HSM auto-unseal(GH-889), ACME auto-issuance for listener TLS(GH-857),
                    recursive listing SCAN verb + ACL(GH-763), web UI returns(GH-940), Raft nonvoters(GH-741)
v2.3.1  2025-06-25  Namespaces(GH-1165), namespace UI(GH-1406),
                    CEL policies for PKI/JWT auth(GH-794, GH-869), KMIP auto-unseal(GH-1144)
v2.4.0  2025-08-28  Declarative self-initialization(GH-1506), inline tokenless auth(GH-1433),
                    LIST/SCAN response filtering(GH-1389), config-file-based audit devices(GH-1700)
v2.5.0  2026-02-04  Standby read scaling(GH-1986), OCI-image-based plugin deployment(GH-1824),
                    unauthenticated rekey endpoint blocked by default(GH-2125, breaking)
v2.6.0  2026-07-14  Namespace sealing(GH-3297), auto-unseal KMS pluginization(GH-2586),
                    sys/workflows(GH-2728), authenticated root token generation(GH-3041), distroless image

Two axes show up here. One is open-sourcing Vault-Enterprise-only features. Namespaces, HSM unsealing, and standby-node read scaling (the equivalent of upstream's performance standby) are all features that live in Vault's Enterprise doc tree. The other is a direction upstream doesn't have at all — things like transactional storage, CEL policies, declarative self-initialization, and inline auth aren't copied from the Enterprise catalog; they're the fork's own design. The project's own explainer posts on transactional storage and paginated LIST, published in July 2026, lay out this differentiation axis themselves (read with that self-description caveat in mind).

Namespaces — The Moment an Enterprise Feature Crossed Over, and Beyond

The most symbolic divergence is namespaces. In Vault, namespaces are the foundation of multi-tenancy and a large share of the reason to buy Enterprise, and OpenBao shipped them open source in v2.3.1 (2025-06-25). The changelog's phrasing is interesting — "application API compatible with upstream's implementation." It states support for both path-based routing (/my-namespace/secrets) and X-Vault-Namespace header routing, and the official announcement post wrote that it "maintains API compatibility with Vault Enterprise to provide a smooth migration path." Compatibility isn't the goal — it's the migration incentive.

And three days ago, v2.6.0 went a step further. Namespace sealing — configuring a separate Shamir seal at namespace creation, which in the release notes' own words "partitions tenant storage with distinct cryptographic key material," letting a tenant seal off and block access to just their own namespace without affecting other tenants. By comparison, Vault Enterprise's namespace lock API is documented as "locks the API" — an API-level block. Separating key material is isolation at a different layer, and this is an item that was listed as "under exploration" in the May 2025 announcement post, shipped roughly a year later. It's the most concrete evidence that the fork is moving on its own roadmap, beyond just catching up to the upstream catalog.

That said, read this with restraint. Namespace sealing is a brand-new feature in this release, with no production track record. It's too early to bet multi-tenant isolation on it alone.

The Opposite Direction — What OpenBao Is Removing

If you're weighing a migration, this side matters more. OpenBao removes just as aggressively as it adds.

Storage backends. The OpenBao docs list Raft, PostgreSQL, file, and in-memory (dev only) as the complete set of backends. Vault's backend list — Consul, DynamoDB, S3, and the rest — was pruned at the fork point. Even the file backend was deprecated as of v2.6.0 and will be removed in v2.7.0 (GH-2849). Which means you can't just lift a Vault instance running on Consul storage straight over.

Cloud secrets engines. AWS, Azure, and GCP dynamic-credential engines aren't in the OpenBao core. They're offered as external plugins in the openbao-plugins repo (auth: AWS/Azure/GCP/GitHub; secrets: AWS/Azure/GCP/GCPKMS/Nomad/Consul), and the same README lists "None available at this time" under database plugins — meaning there are no DB engines beyond what's already in core (PostgreSQL, MySQL, Valkey, etc.).

Built-in seals and distributions. v2.6.0 switched auto-unseal to an external-KMS-plugin scheme, and announced that the built-in awskms, azurekeyvault, gcpckms, pkcs11, and similar seals will be removed in v2.7.0. The HSM-only distribution itself is being phased out by v2.7.0. LDAP, Kerberos, and RADIUS plugins are also moving out of the main binary into external plugins (GH-3371).

The direction itself is consistent — shrink the core, push the boundary out to plugins. But from an operator's seat, the v2.6-to-v2.7 upgrade could be a minefield where seal config, storage, and auth methods all get hit at once. This is a release where you really do need to read the DEPRECATIONS section of the notes.

And the biggest missing item isn't even on the deprecation list. Cross-cluster replication — the equivalent of Vault Enterprise's performance/DR replication — simply doesn't exist in OpenBao. v2.5.0's standby read scaling is scaling within a single cluster, and the changelog itself states "results are eventually consistent." If you need multi-region active-active, OpenBao currently has no answer.

Moving in the Same Direction — Security Defaults and CVE Porting

It's not all divergence. On security, the two projects are still entangled.

Hardening unauthenticated operational endpoints is a good example. OpenBao added a listener option to disable unauthenticated rekey in v2.3.1 (2025-06) (CVE-2025-52894, with the changelog citing upstream HCSEC-2025-11 alongside it), flipped the default to blocked in v2.5.0 (2026-02), and added an authenticated root-token-generation endpoint in v2.6.0. Vault also switched sys/rekey and sys/generate-root to authenticated by default in 2.0.0 (2026-04). I can't judge who followed whom, but the dates are as above.

The porting relationship is real too. OpenBao v2.3.2 (2025-08-07) ported 8 of upstream Vault's HCSEC-2025-series security fixes (HCSEC-2025-13 and others), attaching its own CVE numbers (CVE-2025-54996 and others). Even two years post-fork, the code lineage still overlaps enough that a security advisory on one side is a warning for the other side's users too. Whichever one you run, subscribing to both projects' security advisories is the right call.

What You're On the Hook For on the Vault Side — The CE Patch Cliff

If your team runs Vault free (CE), I'd recommend checking the release-header pattern in the Vault CHANGELOG yourself. Here's what's observable.

• The last CE patch in the 1.21 series is 1.21.4 (2026-03-05). Starting 2026-04-14, when Vault 2.0.0 hit GA, 1.21.5 ships tagged "Enterprise." The 1.20 series followed the same pattern — from the day 1.21.0 shipped (2025-10-22), 1.20.5 became Enterprise-only.
• In other words, the moment a new minor ships, CE security patches for the previous branch stop. The only way to keep getting patches on CE is to always ride the latest minor.
• Long-term support is explicitly a paid feature. The LTS docs describe "1 year of base maintenance plus a 1-year LTS extension," flagged Enterprise-only.

This isn't a conspiracy — it's published policy, and it's HashiCorp/IBM's prerogative. But the arithmetic of "it's Vault CE, so it's free stable operation" leaves out the cost of the upgrade treadmill, and you should choose with that in mind. For reference, OpenBao isn't an organization promising free support forever either — it's an OpenSSF community project. Per the 2025-2026 roadmap issue, 741 commits and 287 contributors over the past year (the project's own tally) are the entirety of its sustainability story. If your organization needs a vendor SLA, that's something to weigh coldly too.

So, What Should You Pick

General tool comparisons live in DevOps Secrets Management 2026 Deep Dive - Doppler, Infisical, HashiCorp Vault, AWS Secrets Manager, 1Password CLI, Bitwarden Secrets, SOPS, age, so this section sticks strictly to the fork dynamic.

When OpenBao is a real candidate

• BUSL/vendor lock-in is a blocker under your organization's policy, and your storage can converge on Raft (or PostgreSQL)
• You need multi-tenancy (namespaces) but Enterprise licensing costs aren't justified — this one feature gap alone is a sufficient reason for some organizations to move to the fork
• Kubernetes/JWT/PKI/KV/Transit-centric workloads — this path is fully covered in core, plus you get operational conveniences upstream doesn't have, like CEL policies and self-initialization

When staying on Vault is the right call

• You need multi-cluster replication (performance/DR) — OpenBao has no counterpart
• AWS/Azure/GCP dynamic credentials are on your critical path — on OpenBao that becomes a dependency on external plugins, and you own the operational burden and maturity risk yourself
• A vendor support contract and LTS are audit/regulatory requirements — that requirement itself is the reason to buy Enterprise

What not to do, either way — assume that "API-compatible" means "drop-in." Storage backends, seal configuration, and plugin setup differ, and once you factor in OpenBao's v2.7.0 deprecation schedule, migration is a project, not a drop-in swap. Regardless of whether you migrate, reading the DEPRECATIONS and SECURITY sections of both projects' release notes every quarter is the minimum defense in this domain.

Closing

The picture two years into the fork sums up like this. OpenBao brought namespaces, HSM unsealing, and read scaling — once Enterprise-only — into open source, and has started shipping features upstream doesn't have, like v2.6.0's namespace sealing. At the same time, it's aggressively trimming its core, building real incompatibility — storage, cloud engines, seals — underneath a surface-level compatibility with Vault. Vault's IBM ownership has been settled at the license-file level, and with the jump to 2.0, it maintains a structure that asks CE users to chase the latest minor and asks organizations that need long-term support to buy Enterprise.

Organizations exist for whom either side is a reasonable choice. But most writing in this space is written on top of one side's interests or the other — as with the primary sources this post links to, I'd recommend grounding your own judgment in release notes and commits and checking it yourself.

References

• OpenBao CHANGELOG · v2.6.0 release notes · v2.0.0 release notes
• OpenBao namespaces announcement (2025-05-30) · 2025-2026 roadmap issue #1974
• openbao-plugins — external plugin list · OpenBao storage docs
• OpenSSF — OpenBao migration announcement (2025-06-17)
• IBM Newsroom — HashiCorp acquisition completed (2025-02-27)
• Vault CHANGELOG · LICENSE licensor-change PR #31826 · Vault LTS docs
• Vault namespace lock API docs