OpenBao 实战笔记：从上手到生产部署（已更新至 v2.7.2） - 张善友
内容提要
OpenBao 是 Vault 的 MPL-2.0 开源分叉，API 与 CLI 高度兼容。文章基于 v2.7.2，介绍安装、KV、数据库动态凭证、PKI、Transit、AppRole 与 Kubernetes 认证、策略与 Control Group、Shamir 与插件化 Auto Unseal、Raft/PostgreSQL 高可用、审计监控、K8s 集成及备份运维，并强调 2.7.2 修复 11 个安全漏洞，应尽快升级。
延伸解读
升级到 2.7.2 不只是修漏洞
文章列出的 11 个漏洞覆盖 AppRole、Kubernetes Auth、Transit 和 SSH 等核心路径，其中 Secret ID 过期仍可登录、SA 吊销后仍能续租都属于认证绕过类问题。对已部署 2.5.x 或 2.6.x 的团队，升级前还需先处理 awskms、pkcs11 等 Seal 插件化带来的配置变化，否则可能出现升级后无法 Unseal 的情况。
Seal 插件化改变了运维边界
2.7 把云厂商 KMS 和 PKCS#11 的 Seal 从主二进制拆成插件，好处是插件崩溃可单独重启、支持热加载和自定义 SDK，但也意味着升级顺序变得关键：必须先在 plugin_directory 注册好插件再升级，否则实例起不来。同时 KMS 密钥一旦不可用或被删除，集群就无法启动，需要配合防删除保护来管理。
Raft 与 PostgreSQL 的取舍依据
文章给出的判断标准很实际：不想额外维护 Raft 集群、已有成熟 PG 运维体系的团队可选 PostgreSQL 后端，2.7 起还支持 Standby 读水平扩展，但仅限物理复制。代价是备份方式不同——Raft 用 snapshot API，PG 后端则要依赖 pg_dump、WAL 归档等自有体系，恢复流程需要单独演练。
动态凭证的价值在缩短暴露窗口
数据库动态凭证按需生成、到期自动删除，配合 default_ttl 控制在一小时内，能显著减少长期密码散落在配置中的风险。文章还提醒配置完连接后立即执行 rotate-root 轮换管理员密码，避免初始凭据被直接使用。应用侧则需在 Lease 到期前续租，或交给 Agent 统一处理。
Q&A
OpenBao 和 HashiCorp Vault 是什么关系？为什么会有这个项目？
OpenBao 是 HashiCorp Vault 的开源分叉，采用 MPL-2.0 许可证，现由 Linux Foundation 下的 LF Edge 托管。起因是 2023 年 8 月 HashiCorp 将 Vault 从 MPL-2.0 改为 BSL 许可证并限制竞争性使用，社区因此 fork 出 OpenBao。它的 API 和 CLI 与 Vault 高度兼容，命令行工具名为 bao，用法几乎照搬 Vault。
为什么必须尽快升级到 OpenBao 2.7.2？
2.7.1 和 2.7.2 一共修复了 11 个安全漏洞，包括 AppRole 的 Secret ID 过期后仍能认证、Kubernetes Auth 在 Service Account 被吊销后还能续租、Transit 导入备份时的路径遍历、SSH 证书模板默认允许通配符等。低于 2.7.2 的部署都应尽快升级。
OpenBao 的 Unseal Key、Root Key 和 Encryption Keyring 之间是什么关系？
OpenBao 的安全核心是多层加密链：Unseal Key（由操作员持有或外部 KMS 插件托管）加密 Root Key，Root Key 加密 Encryption Keyring，Encryption Keyring 再加密存储里的所有数据。请求处理路径为：Listener 终止 TLS → 一致性检查（X-Vault-Index）→ 审计 → Token 验证 → ACL 评估（可能触发 Control Group 审批）→ Secret Engine 处理 → Barrier 加密落盘。
OpenBao 的动态数据库凭证怎么配置和使用？有什么最佳实践？
先启用 database Secret Engine，配置 PostgreSQL 连接（plugin_name、connection_url、allowed_roles），再创建角色并指定 creation_statements、revocation_statements、default_ttl 和 max_ttl。应用通过 bao read database/creds/readonly 按需获取有时效的账号密码，到期自动删除。经验：default_ttl 控制在 1 小时以内；应用要在 Lease 到期前主动续租或交给 Agent；配置完连接后马上执行 bao write -force database/rotate-root/my-postgresql-db 轮换管理员密码。
OpenBao 2.7 的 Auto Unseal 插件化有什么变化？升级时要注意什么？
2.7 将云厂商 KMS（awskms、gcpckms、azurekeyvault 等）和 PKCS#11 的 Seal 全部从主二进制中拆出，只有 Transit Seal 仍内置。配置需分两步：先用 plugin "kms" "awskms" 注册插件，再写 seal "awskms" 配置。好处是插件崩溃会自动重启、SIGHUP 可热加载配置、运行中可升级插件。升级注意：如果老版本在用云厂商 Seal，升到 2.7 之前必须先装好并注册插件，否则升完无法 Unseal。
OpenBao 生产环境应该选 Raft 还是 PostgreSQL 作为存储后端？备份方式有何不同？
生产推荐 Integrated Storage（Raft），无需额外维护 Consul，三节点起步且节点数为奇数，同 Region 部署节点间延迟压在 10ms 内。如果团队已有成熟 PostgreSQL 运维体系，也可用 PostgreSQL 后端（ha_enabled=true，2.7 起支持读水平扩展，但只支持 PG 物理复制）。备份方式不同：Raft 用 bao operator raft snapshot 做快照并异地归档；PostgreSQL 后端没有快照 API，直接用 pg_dump、WAL 归档或云数据库快照等 PG 自身备份体系。
OpenBao 的 Control Group 是什么？适合用在哪些场景？
Control Group 是 2.7 新增的审批控制机制，类似银行金库的双人规则。在策略中通过 control_group 块挂审批，指定审批者身份组和所需批准数。适合读生产根凭证、改 Root CA、导出 Transit 密钥等高危操作。例如对 secret/data/prod/root-credentials 的 read 操作要求 security-approvers 组中 1 人批准。
应用接入 OpenBao 有哪几种方式？Kubernetes 环境推荐哪种？
四种接法按环境选：直接调 API（控制力最强，但要自己管 Token 生命周期）、Agent（虚机/裸机首选，支持 Auto Auth、本地缓存、模板渲染、API 代理）、K8s Injector（注解驱动零侵入，密钥落在 Pod 的 /vault/secrets/ 目录）、CSI Provider（标准卷接口挂载）。Kubernetes 环境推荐用 Injector 或 CSI Provider，认证走 Kubernetes Auth，通过 ServiceAccount 绑定角色和策略。
