openbao/openbao

解决什么问题

一个稍具规模系统里，密钥会不断堆积：数据库密码、API key、服务间调用凭证。把它们塞进配置文件或共用密码库，很快就会在审计、轮换和短期凭证上崩掉。OpenBao 是一个密钥管理服务：写入存储前先加密，还能按需为 AWS、SQL 数据库等系统签发凭证，并在租约到期后自动吊销。

有什么不同

OpenBao 是 HashiCorp Vault 的分叉，起因是 Vault 改用了非 OSI 许可证，现在由 OpenSSF 下开放治理的社区维护。与「KMS + 自己写轮换脚本」相比，它把租约、吊销树和可插拔的 secrets engine 装进一个服务里。与 Vault 本身相比，它押注的是许可证清晰和社区路线，而不是商业公司的产品节奏；与 SOPS 加 KMS 这类轻量方案相比，它重得多，能力也强得多。README 列出的仍是继承自 Vault 的核心模型：加密存储后端、动态密钥、加密即服务、租约与吊销。README 没有给出与 Vault 的兼容性或迁移数据，这部分要自己看文档站确认。

适合谁

适合有多个服务、有真实审计要求的平台与安全工程师，尤其是想要 OSI 许可证基础设施、或已在跑 Vault 并对其许可证心存疑虑的团队。如果只是想在 CI 里加密几个文件，SOPS 或云厂商的密钥管理更省事。没有专人运维有状态、高可用服务的小团队应另找方案。

上手成本

它是 Go 服务：只有从源码构建才需要 Go 工具链，生产环境则意味着要运行一个带存储后端（README 提到磁盘和 PostgreSQL）的有状态服务，并自行设计解封（unseal）方案。开发模式一条命令就能起服务（go run . server -dev），但那不是生产用法。README 明确说明把主模块当库引入不受支持，只有 api/v2 和 sdk/v2 是给外部导入的。许可证为 MPL-2.0。运维上，分叉继承了 Vault 的概念，也继承了生态缺口：插件、解封/KMS 集成和 Vault 专用工具都要重新验证。

点评

这不是一个刚起量的新项目：2023 年底创建，已有 8,686 stars，最近 Go 月度榜以 +1,225 stars 排到第 8，Hacker News 上最热的讨论来自 2023 年 12 月、314 分。这些信号更像治理驱动的稳定采用，而不是发布期炒作。技术内核因为继承而成熟，真正的风险在生态与迁移摩擦，而不是代码能不能跑。2026 年评估密钥管理时，OpenBao 值得和 Vault 一起认真比较；如果指望一个周末就完成无痛替换，请先预留迁移时间。