2026 年 9 月 23 日，OpenBao 在同一天发布了 v2.7.0 和 v2.6.3 两个版本。前者是半年一度的功能版本，带出七项新特性；后者是一次紧急安全回移，九个安全漏洞（每个都有 GHSA 编号）在同一天完成修复并回移到稳定分支。这个托管在 Linux Foundation OpenSSF 之下、从 HashiCorp Vault 分叉而来的密钥管理项目，正处在它诞生以来存在感最强的阶段：6 月，NVIDIA 官方文档确认其 Mission Control 平台采用 OpenBao 作为集群密钥后端和内部证书颁发机构；9 月下旬，项目以每天三百多个 star 的速度登上 GitHub Trending。
一天修复九个漏洞，问题出在哪
先把 v2.6.3 里那批安全修复拆开看，它们共同指向一个攻击面：请求在进入 ACL 策略评估之前和之后的边界地带。
九个漏洞可以按攻击面分组，第一组问题出在策略缓存这一层。LRU 策略缓存存在跨命名空间穿越（GHSA-mjch-vcw3-hhmf）：OpenBao 在 2.4 版本引入了命名空间，让多租户各自持有独立的挂载、策略和审计配置，安全模型的前提是 A 租户的策略解析永远不会触及 B 租户。缓存键没有把命名空间身份完整纳入，命中缓存时返回了错误租户的策略解析结果，形成非预期的跨命名空间访问。这是多租户系统最经典的缓存类漏洞形态，与 2015 年前后各家 CDN 厂商的 Web 缓存投毒系列问题同构，只是发生在策略引擎内部。
插件子系统拿到两个编号。一个是插件启动时的命令名解析（GHSA-j6wc-jpvg-xfxq）：修复前插件命令名没有强制约束在 plugin_directory 之内，构造特定名称可以触到目录之外的路径；另一个是 sys/plugins/catalog/* 写接口没有锁定在根命名空间（GHSA-cg72-x35g-xfp8），命名空间内的管理员本不该有权限注册全局插件。两条修复合起来，把「谁能注册插件」和「插件能执行什么」两个问题都收窄了。
其余修复覆盖了几类常见疏漏：quit 和 cache-clear 这类运维端点在配置了 require_request_header = true 后没有真正校验 X-Vault-Request 请求头（GHSA-8gmq-wv9h-fcwp），这个头是 Vault/OpenBao 用来防御 CSRF 类跨站请求的机制；ACME 证书签发流程放行了未经验证的 SAN（GHSA-x8fg-h69x-p28f），攻击者可能借自动签发流程拿到不受控域名的证书；TypeKVPair 和 TypeHeader 类型处理畸形请求时，未脱敏数据以明文进了审计日志（GHSA-8xxq-mq9m-xmhw），对密钥管理系统来说，审计日志泄露等同于二次泄露源；OIDC 提供方移除了对 prompt=none 静默重定向的支持（GHSA-2cjw-94fw-wqjx），堵住利用已有会话静默完成身份交換的路径；被拒绝的 ACL 策略模板求值错误被静默吞掉（GHSA-hr5j-3j78-4vh2），管理员看到的策略语义和实际执行的语义出现了偏差。
九个漏洞里没有需要重启全集群的远程代码执行，但作为一个密钥管理系统的补丁包，修复的正好是「权限边界是否真的存在」这类问题，建议所有生产部署直接升到 v2.6.3 或 v2.7.0。
External Keys：密钥可以不放在库里
v2.7.0 的特性清单里，架构意义最大的是 External Keys（GH-3956）。
此前 OpenBao 的 PKI 和 Transit 引擎有一个共同前提：被签名或加密用的私钥材料托管在 OpenBao 内部存储里，由存储加密层（配合 Auto Seal 的 HSM/KMS 根密钥）保护。这在多数场景够用，但合规场景常出现另一种要求：根私钥必须留在硬件安全模块（HSM）里，软件系统只调用、不持有。
External Keys 把这个口子正式打开了。PKI 和 Transit 现在可以通过 /sys/external-keys 接口把密钥操作映射到 KMS 插件上：PKI 引擎用外部私钥签证书，Transit 引擎用外部密钥材料做签名、验签、加密、解密，密钥本体始终不出 KMS。接口设计和 Auto Seal 一样是 provider 无关的，官方仓库 openbao-plugins 里已带 PKCS#11 插件（对接主流 HSM），Transit 键后端则内置。对已经部署了 HSM 的组织，这是从 Vault 商业版特性表里划掉一行的重要一格。
这个特性和 2.6.0 就已宣布的插件化拆分是同一趋势的两步：v2.7.0 起，pkcs11、awskms、azurekeyvault、gcpckms、alicloudkms、ocikms 这些 seal 不再内置在主程序里，全部改为外部插件安装；LDAP、Kerberos、RADIUS 认证引擎和 LDAP 密钥引擎同样移出主发行版。主二进制变小了，发行版里留下的都是纯 Go 实现、无外部依赖的部分，与 HSM 厂商 SDK 相关的组件按需安装。这是开源项目在「发行版体积、供应链审计面、许可边界」之间的一种取舍方式。
后量子签名与纯 PQC TLS 进入默认工具箱
第二个大项是后量子密码（PQC）支持，两个 PR 分别覆盖了签名与密钥交换两端。
签名侧，PKI 和 Transit 引擎加入 ML-DSA（GH-3903、GH-3909），即 NIST FIPS 204 标准的 ML-DSA 签名算法，支持 mldsa-44、mldsa-65、mldsa-87 三个参数集，覆盖 CA 签发、CSR、叶子证书全流程，Transit 侧支持生成、导入、导出密钥和纯 ML-DSA 签名的创建与验证。ML-DSA 属于 NIST 2024 年定稿的后量子签名标准家族，设计目标是抵御量子计算机对现有椭圆曲线和 RSA 签名的攻击。
密钥交换侧，服务器、Agent、Proxy 的 TLS 监听器新增 tls_key_exchange_preferences 配置（GH-3769），可以强制使用 X25519MLKEM768、SecP256r1MLKEM768 等混合后量子密钥交换算法，也支持直接挂 ML-DSA 证书。管理平面自身的传输安全因此可以整条切到 PQC。
合规驱动明确的行业（金融、电信、政府基础设施）从 2024 年起陆续收到监管侧的 PQC 迁移时间表，密钥管理系统是迁移的第一站：所有别的系统的密钥都从这里发。OpenBao 把 ML-DSA 和纯 PQC TLS 做进社区版，等于把这条迁移路径的起点成本降到了零。
横向扩展与强一致性：补齐企业级最后两块板
PostgreSQL 存储后端拿到了读扩展能力（GH-3904）。此前 OpenBao 集群的水平扩展路径是集成 Raft 存储：写走主节点，读可以由 standby 节点分担（Standby Reads）。v2.7.0 把同等能力给了 PostgreSQL 后端，开启 ha_enabled 后，standby 节点通过一条指向主节点的 RPC 转发连接建立读通道；主节点领导权长时间丢失时，standby 会自动进入可读状态兜底。限制也写得清楚：只支持 PostgreSQL 物理复制，逻辑复制不适用。
配套的是强一致性控制头（GH-3839）。客户端写入时会拿到 X-Vault-Index 索引值，后续读请求带 X-Vault-Inconsistent 头声明自己的一致性要求：fail 表示节点数据落后就返回 429 加 Retry-After；forward-active-node 表示转发到主节点；await-state 表示在本地等数据追上来，等不到再按配置回退。读扩展的代价永远是读到的数据可能落后，这三个模式把「落后怎么办」的决定权交还给调用方，而不是在系统层一刀切。
这两个特性和 5 月 Open Source Summit NA 上 ControlPlane 的 Alexander Scheel 的演讲主题直接对应：OpenBao 的横向扩展。Adfinis 在 8 月发布的电信客户案例里给出了迁移后的量化结果：十个月完成从专有密钥平台到 OpenBao 的迁移，维护开销减半，许可成本降了 60%。
存储层还有一个值得点名的新后端：PebbleDB（GH-3879），非 HA、基于 LSM 树的本地持久化引擎（CockroachDB 底层同款），定位是替代被移除的 file 后端做单节点持久化。相应地，file 存储后端在 v2.7.0 被移除，bao operator migrate 对 file 后端的支持也标记了 v2.8.0 的移除时间点，单节点部署需要在这两个版本之间完成迁移。
NVIDIA 用它管什么
NVIDIA Mission Control 是 NVIDIA 面向 AI 工厂交付的集群管理软件。其 2.3.1 版官方安装文档单独开了一节讲 OpenBao，原话是：OpenBao 是集群的 secrets 后端和内部证书颁发机构，持有平台组件运行时读取的 KV 数据，并为 cert-manager 签发证书链。
部署形态上有几个可复用的细节。OpenBao 以 Argo CD Application 形式交付，跑上游官方 Helm chart，存储用集成 Raft，引导阶段单节点、之后可以扩到高可用仲裁。自解封用的是静态 32 字节密钥，文档反复强调这把钥匙必须备份在集群之外，丢钥匙且 Raft 卷还在时数据无法恢复。初始化是两次完成：首次空存储启动时自初始化，启用 PKI 与 KV 挂载、构建两级 CA（根 CA 和中间 CA 都在 OpenBao 内部生成，私钥不出进程）、为每个组件建最小权限策略和 Kubernetes 认证角色；之后每次 Argo CD 同步由一个 PostSync Job 做配置加载，KV 写入是 create-only 的，重放同步不会覆盖已在使用中的值。
这套文档实际上是一份来自大型 AI 基础设施用户的部署样本：GitOps 交付、最小权限按组件拆分、内部 CA 与 secrets 后端合一、break-glass 流程文档化。打算把 OpenBao 用于生产环境的团队可以直接参考它的结构。
分叉三年，它走到了哪里
回到 2023 年 8 月，HashiCorp 把包括 Vault 在内的核心产品从 MPL 2.0 改为 BSL 1.1（Business Source License），三年内对生产环境使用构成限制。社区的回应是分叉：OpenTofu 拿走了 Terraform 的开源代码，OpenBao 于 2023 年 12 月公布，交由 Linux Foundation 旗下 OpenSSF 治理，沿用 MPL 2.0。
三年过去，可以核对的事实是：项目发版节奏稳定在每月或每两月一版；主要贡献者名单里有 SAP（数名全职开发者，由欧盟 NextGenerationEU 资助）、ControlPlane、Adfinis、GitLab、Fermilab、Proton、Liquid Reply；SUSE Rancher、Red Hat OpenShift 生态认证相继落地；采用方名单从早期的中小型基础设施团队，扩展到 NVIDIA Mission Control 这样的旗舰级交付平台。IBM 在 2024 年完成对 HashiCorp 的收购后，Vault 社区版的许可条款没有回到 OSI 许可证，这条分叉线没有失去存在的前提。
对使用者的实际意义可以按三种处境概括。已在用 Vault 社区版的团队，迁移窗口依然是官方 bao operator migrate 工具支持的路径，社区的实测经验表明实际可迁移性比文档写的版本线更宽，真正的限制在无插件挂载；在选型新密钥平台且需要 HSM/合规链路的团队，v2.7.0 的 External Keys 和 ML-DSA 把过去要靠商业许可满足的合规项拉进了开源方案的能力范围；管理着多套 OpenBao/Vault 的团队，命名空间与跨命名空间缓存穿越这一对修复（v2.6.3）说明了多租户特性仍在快速迭代期，升级节奏值得跟紧。
密钥管理系统的价值从来不在功能列表的长度，而在于它是否被足够多的重要系统信任。NVIDIA 的采用、九个同日修复的 CVE、后量子密码的社区版落地，是这种信任在 2026 年 9 月的三个具体注脚。
来源：