在 Kubernetes 上跑 OpenBao：用 CloudNativePG 搭建免静态密码的 PostgreSQL 后端
CNCF 博客分享了云原生密钥管理实践：借助 CloudNativePG 运维器为 OpenBao 部署零静态密码的 PostgreSQL 存储集群，通过双向 TLS 证书认证与同步复制保障数据安全与高可用。
作者：核流 Admin · 栏目：资源
在 Kubernetes 集群中集中管理基础设施机密时，密钥管理器本身的底层存储后端如何避免明文密码，一直是架构设计里的典型难题。CNCF 博客近期分享了一套极具参考价值的云原生解法：借助 CloudNativePG 操作器，为开源平台 OpenBao 搭建一套完全摒弃静态密码的 PostgreSQL 存储后端，全程依靠双向 TLS 客户端证书完成身份认证，兼顾了安全合规与高可用。 告别静态密码，双向 mTLS 直连数据库 这套方案的核心在于消灭连接配置中的硬编码凭据。传统做法通常是在 Secret 里保存明文密码，一旦被窃取就会导致全盘失守。而在该架构下，模式所有者与 OpenBao 运行时所使用的两个数据库角色，全部交由 CloudNativePG 的 DatabaseRole 自定义资源动态签发客户端证书。 配合 pg_hba.conf 严格配置的访问规则，数据库只接受持有合法证书的客户端接入。任何尝试以传统账密或明文方式发起的连接，都会被直接阻断。此外，客户端 libpq 默认会拒绝读取权限过于宽松的私钥。方案将 Kubernetes 卷的 defaultMode 显式设为 0640，堵死了容器内私钥权限越界的风险。 法定人数同步复制背后的工程权衡 在数据可靠性方面，架构采用了由 3 个实例组成的 PostgreSQL 18 集群，并配置基于法定人数的同步复制（method: any, number: 1）。在至少存在一个可用备节点时，系统能够实现 RPO=0 的无损故障切换。 但高可靠也有代价。官方在方案中坦诚指出了设计取舍：为了确保数据绝对持久（dataDurability: required），如果在极端情况下所有备用节点全部宕机，主节点将主动暂停写入以防止数据分叉。这意味着系统在可用性与一致性之间选择了后者，宁可短暂拒绝写请求，也绝不冒丢失机密数据的风险。 落地生产必须防住的运维暗礁 将这套方案推向生产时，团队还需要处理两项关键运维细节： 证书热重载缺失：客户端证书默认有效期为 90 天，到期前 7 天会自动轮转。但由于 OpenBao 底层的数据库连接池不会主动重载磁盘文件，平台需要在约 83 天的窗口期内主动触发 Pod 滚动重启，确保新证书顺利生效； 单集群高可用不等同于灾备：当前方案只保障了单集群内部的高可用。面对区域级故障，生产环境仍需借助 Barman Cloud Plugin 将 WAL 归档与备份推至对象存储，并配合跨区域异步副本构筑底线。 作为 HashiCorp 协议变更后的开源替代品，OpenBao 正在成为云原生机密管理的重要选项。这套结合 CloudNativePG 的实践，为去密码化运维提供了一份清晰的落地参考。目前相关实现已在官方仓库完整开源，如果你正准备在生产集群搭建凭据底座，官方项目文档给出的声明式配置很值得借鉴获取。 参考资料 OpenBao：OpenBao: An open-source secret management and encryption platform CloudNativePG：CloudNativePG: Kubernetes operator for PostgreSQL workloads CNCF Blog：Running OpenBao on Kubernetes with a CloudNativePG PostgreSQL backend