Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

引言 — 分叉两年，看发布说明而非情绪
背景 — 在哪里分叉，所有权又是怎么变化的
按版本看实际的分歧 — OpenBao 加了什么
命名空间 — Enterprise 功能跨越边界的那一刻，以及更远处
反方向的分歧 — OpenBao 在砍什么
朝同一方向移动的部分 — 安全默认值与 CVE 移植
Vault 这一边要背的债 — CE 补丁悬崖
那么该选哪个
结语
参考资料

引言 — 分叉两年，看发布说明而非情绪

今天(2026-07-17)距离OpenBao v2.0.0 GA发布正好两年，距离v2.6.0发布只有三天。而这个话题至今仍然阵营分明 — 一边说「转向 BUSL 就是背叛」，另一边说「分叉在功能和支持上都跟不上」。许可证转向本身的来龙去脉，我已经在开源许可证格局梳理一文里梳理过，本文要回答的是另一个问题。分叉到底在哪里真正分道扬镳 — 不是营销话术，而是只看两个项目自己发布的发布说明、变更日志和提交记录能确认的部分。

同属一个分叉家族的 OpenTofu，抢先于上游 Terraform 推出后者没有的功能，这段故事我已经在OpenTofu 的 dynamic lifecycle一文里写过。本文是它在密钥管理领域的版本。

背景 — 在哪里分叉，所有权又是怎么变化的

按时间顺序把能确认的事实列出来，是这样的。

Vault 仓库的LICENSE 文件是 BUSL 1.1，明确写明适用对象是"Vault Version 1.15.0 or later"。也就是说，1.14 系列是最后一个 MPL 代码库。
OpenBao 正是在那个节点分叉出去的。v2.0.0 发布说明明确写道"OpenBao is fully API compatible with Vault 1.14.9"，并声明不支持 Enterprise 功能。GA 是 2024-07-17，那时候连 Web UI 都还没有。
IBM 收购 HashiCorp 已于 2025-02-27 完成(据 IBM 新闻室)。
OpenBao 于 2025-06-17 从 LF Edge 迁移为 OpenSSF 沙箱项目。
2026-03-26，Vault 仓库 LICENSE 里的许可方从"HashiCorp, Inc."变成了"International Business Machines Corporation (IBM)"(在提交 diff里可以直接看到 — 竞品禁止条款的保护对象也变成了"IBM Corp's paid version(s)")。
2026-04-14，Vault 2.0.0发布。这是自 1.0(2018)以来第一次主版本号跳跃，FEATURES 列表里出现了"IBM PAO License Integration" — 一项允许用 IBM 许可证密钥使用 Vault Enterprise 的功能。

收购之后的整合，一路下沉到了许可证文件和功能列表里。接下来看看分叉这一方这些年到底积累了什么。

按版本看实际的分歧 — OpenBao 加了什么

以下内容全部来自OpenBao CHANGELOG和 GitHub 发布页的确认。日期以 GitHub API 记录的发布时间为准。

v2.1.0  2024-11-29  事务性存储(GH-292)、取消挂载表大小上限(GH-622)、
                    PostgreSQL 后端复活 + 分页 LIST(GH-467)
v2.2.0  2025-03-05  PKCS#11 HSM 自动解封(GH-889)、监听器 TLS 的 ACME 自动签发(GH-857)、
                    递归列出 SCAN 动词・ACL(GH-763)、Web UI 回归(GH-940)、Raft 非投票节点(GH-741)
v2.3.1  2025-06-25  命名空间(GH-1165)、命名空间 UI(GH-1406)、
                    PKI・JWT 认证的 CEL 策略(GH-794, GH-869)、KMIP 自动解封(GH-1144)
v2.4.0  2025-08-28  声明式自初始化(GH-1506)、内联无令牌认证(GH-1433)、
                    LIST/SCAN 响应过滤(GH-1389)、基于配置文件的审计设备(GH-1700)
v2.5.0  2026-02-04  待机节点读取扩展(GH-1986)、基于 OCI 镜像的插件部署(GH-1824)、
                    未认证 rekey 端点默认关闭(GH-2125，破坏性变更)
v2.6.0  2026-07-14  命名空间封印(GH-3297)、自动解封 KMS 插件化(GH-2586)、
                    sys/workflows(GH-2728)、认证后生成 root token(GH-3041)、distroless 镜像

这里能看到两条轴线。一条是把 Vault Enterprise 专属功能开源化。命名空间、HSM 解封、待机节点读取扩展(对应上游的 performance standby)全都是在 Vault 里位于 Enterprise 文档树下的功能。另一条是上游完全没有的方向 — 事务性存储、CEL 策略、声明式自初始化、内联认证这类东西，不是照抄 Enterprise 目录，而是分叉自己的设计。项目在 2026 年 7 月发布的事务性存储、分页 LIST两篇解读文章，把这条差异化轴线自己梳理了一遍(这是项目自己的表述，阅读时请留意这一点)。

命名空间 — Enterprise 功能跨越边界的那一刻，以及更远处

最具象征性的分歧就是命名空间。在 Vault 里，命名空间是多租户的根基，也是购买 Enterprise 的重要理由之一，而 OpenBao 在 v2.3.1(2025-06-25)把它开源了出来。变更日志的措辞很有意思 — "application API compatible with upstream's implementation"。文档明确写明同时支持基于路径(/my-namespace/secrets)和 X-Vault-Namespace 请求头两种路由方式，官方公告文章写道"保持与 Vault Enterprise 的 API 兼容，以提供平滑的迁移路径"。兼容性不是目的，而是迁移的诱因。

而三天前的 v2.6.0 又往前迈了一步。命名空间封印(namespace sealing) — 在创建命名空间时配置独立的 Shamir seal，用发布说明的话说是"用不同的加密密钥材料对租户存储做分区"，让某个租户能在不影响其他租户的前提下，单独封印并阻断自己命名空间的访问。相比之下，Vault Enterprise 的命名空间锁定 API在文档里写的是"locks the API" — 一种 API 层面的阻断。密钥材料的分离是另一个层次的隔离，而这正是 2025 年 5 月的公告文章里还写着"探索中"的条目，一年多之后就发布出来了。这是分叉超越追赶上游目录、开始按自己的路线图前进的最具体证据。

当然，读的时候要打个折扣。命名空间封印是这次发布才第一次出现的功能，还没有实战验证的历史。把多租户隔离整个押在这一项功能上，还为时过早。

反方向的分歧 — OpenBao 在砍什么

如果你在考虑迁移，这一边更重要。OpenBao 加得有多猛，砍得也一样猛。

存储后端。 OpenBao 文档里列出的后端，Raft、PostgreSQL、文件、内存(仅限开发)就是全部。Consul、DynamoDB、S3 这些 Vault 的后端列表，在分叉那一刻就被砍掉了。就连文件后端也在 v2.6.0 被预告弃用，将在 v2.7.0 移除(GH-2849)。也就是说，跑在 Consul 存储上的 Vault，没法原样搬过去。

云密钥引擎。 AWS・Azure・GCP 的动态凭证引擎不在 OpenBao 核心里。它们以外部插件的形式由 openbao-plugins 仓库提供(认证: AWS/Azure/GCP/GitHub；密钥: AWS/Azure/GCP/GCPKMS/Nomad/Consul)，而同一份 README 在数据库插件那一项写的是"None available at this time" — 意思是除了核心自带的那些(PostgreSQL、MySQL、Valkey 等)之外，没有别的数据库引擎。

内置 seal 与发行版。 v2.6.0 把自动解封切换成了外部 KMS 插件体系，并预告将在 v2.7.0 移除内置的 awskms、azurekeyvault、gcpckms、pkcs11 等 seal。HSM 专用发行版本身也会在 v2.7.0 之前逐步废弃。LDAP・Kerberos・RADIUS 插件也会从主二进制文件中移出，改为外部插件(GH-3371)。

方向本身是一致的 — 缩小核心，把边界推给插件。但站在运维者的角度，从 v2.6 升级到 v2.7 可能会是一片雷区，seal 配置、存储、认证方式会同时被牵动。这一次，发布说明里的 DEPRECATIONS 部分是真的要认真读。

而被砍掉的东西里最大的一项，甚至都不在弃用预告清单上。跨集群复制 — 对应 Vault Enterprise 的 performance/DR 复制功能，OpenBao 里根本没有。v2.5.0 的待机节点读取扩展是单一集群内部的扩展，变更日志自己就写明"结果是最终一致的(eventually consistent)"。如果需要跨地域的主主(active-active)架构，OpenBao 目前给不出答案。

朝同一方向移动的部分 — 安全默认值与 CVE 移植

分歧不是全部。在安全这一块，两个项目至今仍然纠缠在一起。

未认证运维端点的加固就是个好例子。OpenBao 在 v2.3.1(2025-06)加入了可以关闭未认证 rekey 的监听器选项(CVE-2025-52894，变更日志同时标注了上游的 HCSEC-2025-11)，在 v2.5.0(2026-02)把默认值反转为关闭，又在 v2.6.0 加入了认证后生成 root token 的端点。Vault 也在 2.0.0(2026-04)把 sys/rekey 和 sys/generate-root 改成了默认需要认证。谁跟谁学的，我没法判断，但日期就是上面这些。

移植关系也是真实存在的。OpenBao v2.3.2(2025-08-07)移植了上游 Vault 的 8 项 HCSEC-2025 系列安全修复(HCSEC-2025-13 等)，并为它们各自分配了自己的 CVE 编号(CVE-2025-54996 等)。分叉两年之后，代码血缘依然有重叠，这意味着一边的安全公告，对另一边的用户来说同样是警报。不管你运维的是哪一边，两边的安全公告都订阅才是对的做法。

Vault 这一边要背的债 — CE 补丁悬崖

如果你的团队用的是免费版(CE)Vault，我建议你亲自去核实一下Vault CHANGELOG里发布标题的规律。能观察到的事实是这样的。

1.21 系列的 CE 补丁止步于 1.21.4(2026-03-05)。从 Vault 2.0.0 GA 的 2026-04-14 起，1.21.5 就带上了"Enterprise"标记。1.20 系列也是同样的模式 — 从 1.21.0 发布那天(2025-10-22)起，1.20.5 就变成了 Enterprise 专属。
也就是说，新的次版本一发布，前一个分支的 CE 安全补丁就停了。要在 CE 上持续拿到补丁，唯一的办法就是始终跟着最新的次版本走。
长期支持明确是付费功能。LTS 文档在 Enterprise 专属的提示旁边说明了"基础维护 1 年 + LTS 延长 1 年"。

这不是阴谋论，而是公开的政策，也是 HashiCorp/IBM 的权利。只是"用 Vault CE 就能免费稳定运维"这笔账，漏算了升级这台跑步机的成本，选的时候得把这一点算进去。顺带一提，OpenBao 也不是一个承诺永远免费提供支持的组织，它是 OpenSSF 旗下的一个社区项目 — 按照2025-2026 路线图，过去一年 741 次提交、287 位贡献者(项目自己的统计)，就是它可持续性的全部家底。如果你的组织需要厂商 SLA，这一点也得冷静地单独衡量。

那么该选哪个

工具对比的一般性讨论在密钥管理工具梳理一文里，这里只针对这场分叉的格局做梳理。

OpenBao 是实际候选项的情况

BUSL・厂商锁定在组织政策上是个障碍，且存储可以收敛到 Raft(或 PostgreSQL)
需要多租户(命名空间)，但 Enterprise 许可证费用无法被正当化 — 光是这一项功能差距，就足以让某些组织决定转向分叉，这样的组织是真实存在的
以 Kubernetes・JWT・PKI・KV・Transit 为核心的工作负载 — 这条路径核心里全都有，还附带了 CEL 策略、自初始化这类上游没有的运维便利

留在 Vault 更合适的情况

需要多集群复制(performance/DR) — OpenBao 没有对应物
AWS・Azure・GCP 的动态凭证是核心路径 — 在 OpenBao 上这会变成对外部插件的依赖，运维负担和成熟度风险得自己扛
厂商支持合同和 LTS 是审计・合规要求 — 这项要求本身就是购买 Enterprise 的理由

不管选哪边都不该做的事 — 假设"API 兼容就等于无缝替换"。存储后端、seal 配置、插件构成都不一样，再叠加上 OpenBao 的 v2.7.0 弃用时间表，迁移就不是无缝替换，而是一个项目。不管迁不迁移，每个季度都去读两边发布说明里的 DEPRECATIONS 和 SECURITY 部分，是这个领域里最低限度的防御。

结语

分叉第二年的图景可以这样概括。OpenBao 把曾经 Enterprise 专属的命名空间・HSM 解封・读取扩展带进了开源世界，又开始像 v2.6.0 的命名空间封印那样，抢先推出上游没有的功能。与此同时，它在激进地削减核心，在与 Vault 表面兼容之下，堆积起存储、云引擎、seal 这些实质上的不兼容。Vault 的 IBM 归属已经在许可证文件层面被坐实，版本号跳到 2.0 的同时，维持着一套要求 CE 用户追赶最新次版本、要求需要长期支持的组织购买 Enterprise 的结构。

两边各自都有让它成为合理选择的组织存在。只是这个领域的文章大多是站在某一方的利益上写出来的 — 就像本文所链接的这些一手资料一样，我建议你把判断的依据落到发布说明和提交记录上，亲自去核实。