如何在企业中使用 OpenBao：实用指南及替代方案

当一家公司开始认真对待凭证安全时，它很快就会发现，将密码、令牌和证书分散在无数位置（文件、环境变量、内部维基等等）无异于自取灭亡。OpenBao 正是在这种情况下应运而生的，它是 Vault 的一个社区分支，旨在填补 HashiCorp 许可证变更后留下的空白，同时又不放弃真正的开源模式。

如果您使用 Argo CD 和 Helm 部署 OpenBao，并希望将 GitOps 理念发挥到极致（包括策略、配置、初始化和解封都以代码形式实现），感到有些迷茫是很正常的：它涉及众多组件（Selo、存储后端、高可用性、身份验证方法、插件等等），并且还有多种无需人工干预即可实现所有操作自动化的方案。让我们一起理清这些难题，并在此过程中，将 OpenBao 与其他可能适合您组织的密码库和密钥管理器进行比较。

OpenBao是什么？它存在的意义是什么？

OpenBao 起源于 HashiCorp Vault 的一个分支，由社区推动并得到 Linux 基金会的支持。其导火索是 HashiCorp 将许可证更改为 BSL 1.1，该许可证限制了其代码在与其云服务存在商业竞争关系的平台上的使用——这与 Linux 基金会自身的要求以及许多传统的开源商业模式不符。

多家公司和贡献者（包括参与 Open Horizo​​n 项目的 IBM 员工）并没有完全放弃 Vault 生态系统，而是决定基于 Vault 的 1.14.x 分支进行开发，所有内容仍采用MPL 2.0许可，并在一个开放的、社区主导的治理模式下继续开发，独立于任何单一供应商。他们的目标是在确保项目真正自由发展的同时，最大限度地保持与 Vault 的兼容性（命令、API、SDK、插件）。

OpenBao 继承了 Vault 的理念：提供集中式服务，让用户可以从单一入口管理密钥、证书、令牌和访问策略，并具备审计、动态轮换和细粒度控制功能。但从现在开始，OpenBao 的发展路线图第一阶段的重点是整合和改进现有功能（安全存储、轮换、细粒度访问控制），并加强审计和合规能力，以更好地满足受监管组织的需求。

在后续阶段，OpenBao 社区计划扩大对不同云和分布式架构的支持，改进 API 和插件系统，并促进与其他 DevOps、可观测性和安全工具的深度集成，从而使将其连接到您的生态系统不再是一场漫长的旅程。

OpenBao 与 Vault 及其他密钥管理工具的比较

OpenBao 的一大吸引力在于，如果您已经了解 Vault，那么您实际上就知道如何使用它：bao CLI 保留了Vault的大部分命令和使用模式，存储后端和引擎（KV、PKI、Transit、SSH、数据库）的行为非常相似，并且与 Kubernetes、Terraform 或 Ansible 的集成遵循相同的思维模型。

与KeePassXC、Bitwarden、Passbolt 或 Psono 等传统密码管理器相比，OpenBao 更胜一筹：它专为应用程序和基础设施密钥（令牌、数据库凭证、证书、加密密钥、SSH CA 等）而设计，而非用户日常使用的“人名”密码。其优势在于能够与 CI/CD 流水线、Kubernetes、自动化工具和企业身份系统无缝集成。

与 Cyber​​Ark Conjur OSS 等企业级替代方案相比，OpenBao 通常更容易理解和部署，并在灵活性和复杂性之间取得了良好的平衡。Conjur 非常强调“策略即代码”的概念，拥有自己的 DSL 和极其细粒度的访问控制，专为具有极高合规性要求和专用安全团队的环境而设计；OpenBao 通过 HCL/JSON 策略和 RBAC 模型实现了类似的功能，但学习曲线更为平缓。

如果您正在寻找一款专注于开发者体验和现代用户体验的密钥管理器（例如 Inphysical 或 Phase），OpenBao 可能需要您进行一些前期准备工作，但作为回报，它为您提供了一种经过多年生产验证的安全设计，这得益于 Vault 的传承以及一个以厂商中立的方式推动其发展的社区。

公司内部配置 OpenBao：配置文件和关键选项

在开发模式之外，OpenBao 通过配置文件进行配置。您可以使用 HCL 或 JSON 格式，除了单个配置文件之外，您还可以使用配置目录：任何以.hcl或.json结尾的文件都会按字母顺序加载。如果同一个顶级键出现在多个文件中且该键不是列表，则最后一个文件中的值优先；如果是列表（例如，多个监听器），则会将列表元素添加到配置中。

通常启动服务器的方法是输入`bao server -config=/path/to/config`。接下来，对于企业部署，您需要定义的最重要的几个部分是：

• 存储：用于存储持久数据的后端。
• ha_storage：如果存储后端不支持高可用性，则协调 HA 模式的后端。
• 倾听者: OpenBao 如何以及在哪里监听 HTTP(s) 请求。
• 密封：密封类型（自动解封、HSM、KMS 本地部署等）。
• 全局参数，例如 集群名称租约的 TTL、日志记录、用户界面、审计和插件。

`storage`指定用于持久化状态的后端（例如，Raft、Consul 等集成存储）。如果该后端支持高可用性协调，您可以直接在其中定义高可用性选项；否则，您可以使用 ` ha_storage`指定专门用于协调集群节点的后端。

在监听器部分，您将定义协议、地址和端口、TLS 证书（如果适用）、每个请求的最大时间（或者您可以让它使用全局默认值 default_max_request_duration）等。在企业环境中，通常会在负载均衡器后面部署一个或多个监听器，以执行 TLS 终止或额外的身份验证。

另一个关键要素是密封块，您可以在这里选择“安全屏障”的加密方式。简而言之：您可以选择使用分密钥方案（Shamir）并手动解封，或者配置使用密钥管理系统 (KMS) 或硬件安全模块 (HSM) 的自动解封。稍后我们将讨论如何在没有公有云连接的环境中实现自动化。

OpenBao在全球范围内允许您调整以下参数：

• 默认租约期限 y 最大租期：令牌和密钥的默认和最大时间，用“30s”或“1h”之类的后缀表示。
• 默认最大请求持续时间：服务器在终止请求之前，每个请求的最大等待时间。
• LOG_LEVEL日志格式和轮换，包括按大小或时间轮换。
• 激活 ui 网络、遥测、内部检查端点或对存储的原始访问（后者非常敏感）。
• 选项 用户锁定 多次尝试失败后封禁用户。

文件安全、插件和审计

在生产环境中，建议启用文件权限控制；OpenBao 可以验证目录和配置文件是否归运行该进程的用户所有，并且这些文件对组或其他用户没有写入或执行权限。此功能可通过环境变量VAULT_ENABLE_FILE_PERMISSIONS_CHECK启用。

启用此检查后，如果您需要插件目录或插件二进制文件属于其他用户（出于打包或安全原因），可以在设置中调整`plugin_file_uid`和`plugin_file_permissions`。这样，即使 UID 和八进制权限与进程用户不匹配，OpenBao 也能知道哪些 UID 和八进制权限是可接受的。

关于插件，OpenBao 支持从 OCI 镜像进行声明式注册和下载。您可以启用`plugin_auto_download`和`plugin_auto_register`，以便服务器根据需要自动下载和注册插件，并使用`plugin_download_behavior`控制发生错误时的行为（例如，将插件下载失败设置为致命错误）。

审计是另一个敏感领域：OpenBao 允许您在启动时定义审计设备（文件、套接字、系统日志等），并且可以选择通过设置`unsafe_allow_api_audit_creation`来启用通过 API 创建新设备的功能。明智的做法是仅在需要自动执行特定更改时启用此功能，并在需要时将其禁用以减少攻击面。

OpenBao、GitOps 和 Argo CD：策略和配置即代码

当您使用官方 Helm Chart 部署 OpenBAO 并使用 Argo CD 进行管理时，通常的做法是将所有内容都视为代码：Kubernetes 清单、Helm 值、服务器配置、策略、身份验证方法，甚至包括初始化和解封过程。难点在于如何决定哪些操作由 Kubernetes/Argo 执行，哪些操作需要在 HCL/JSON 文件中定义，以及哪些操作需要通过脚本或初始化作业来执行。

常见的做法是在 Git 仓库中包含一个文件夹，其中包含 OpenBao 的配置（HCL 或 JSON 格式），并将其作为 ConfigMap/Secret 挂载到服务器的 Pod 中。该文件夹定义了存储、监听器、密封、TTL、日志记录以及诸如 UI 或遥测等参数。这一层完全基于基础设施，非常适合 GitOps。

基于此，许多组织使用第二层代码来管理策略、引擎启用、角色和身份验证方法：幂等脚本（shell、Go、Python）或基础设施即代码 (IaC) 工具（Terraform 或 OpenTofu），它们通过与 API 通信将配置应用到 OpenBao。这些脚本从以下位置启动：

• Argo CD 在服务器后端部署的 Kubernetes 作业。
• 当策略库发生更改时运行的 CI/CD 流水线。
• 或者根据环境（开发、预处理、生产）的不同，采用两者的混合方式。

通常以代码形式进行版本控制的资源包括：

• 政策 在 HCL/JSON 中，具有其路径和功能（读取、列表、更新、sudo…）。
• 身份验证方法 （Kubernetes、Apple、OIDC、LDAP）及其配置。
• 坐骑 密钥（KV v2、PKI、Transit、DBDD、SSH）及其轮换参数。
• 角色 以及身份（服务帐户、AD 组）与策略之间的链接。

在成熟的 GitOps 方法中，对这些定义的每一次更改都会经过审核，并以可复现的方式应用，您可以审计策略和访问权限的完整历史记录。如果您拥有 ISO 27001 等认证或其他需要可追溯性和变更控制的标准，这将尤其有用。

实现 OpenBao 的自动封禁和解封。

在无人干预的情况下运行 OpenBao 时，最大的难题在于密钥的封禁/解封过程。OpenBao 的“安全屏障”采用密钥加密，在经典模式下，该密钥按照 Shamir 方案被分成若干部分。要启动服务器并访问密钥，需要一定数量的密钥部分，这些部分通常由人工操作员输入。

在本地环境或客户现场部署的设备上，由于您无法直接控制，也无法保证有人会手动输入密钥，因此这种方法并不实际。此外，如果环境需要完全自主运行，您也不能依赖AWS KMS 或 GCP KMS 等公有云 KMS来实现自动解封。

在这些情况下，OpenBao自动解封最常见的模式包括：

• 使用一个 HSM 或本地 KMS （本地部署的硬件或软件）与 OpenBao 集成，作为自动印章。
• 骑 内部解封服务 它存储 Shamir 的加密密钥，并以受控方式将其提供给 OpenBao。
• 选择以自动开封为标准配置且人工交互需求较少的替代工具。

如果选择本地 HSM/KMS，流程与云端类似：您需要配置相应的安全模块（HSM、硬件安全模块或本地安装的第三方 KMS）的加密隔离，之后，服务器会在能够与该系统通信时自动解除加密隔离。这是一种可靠的方案，但需要投资特定的硬件或额外的安全软件。

内部“解封服务”方案通常涉及将 Shamir 的密钥存储在您组织控制的存储环境中（例如，另一个密钥库或硬件安全模块 HSM），并使用机器密钥进行加密。此外，还会提供一个小型服务，该服务在检测到 OpenBao 被封禁后，会将必要的组件发送到解封 API。虽然这增加了架构的复杂性，但避免了日常的人工干预。

最后，如果您的主要需求是完全自主且可自行管理的设备，那么您可能需要考虑专为简单的本地部署而设计的密钥管理器，这类管理器将自动解封功能“打包”得更完善，所需的编排工作也更少。在这种情况下，一些专用的嵌入式软硬件解决方案可能比 OpenBao 更合适。

如何在应用程序中使用 OpenBao 客户端

除了将其作为中心服务进行管理之外，您还需要将 OpenBao 与您的应用程序集成，这样它们就不再需要在代码或配置文件中存储密钥。基本流程始终相同：启动 OpenBao，通过应用程序进行身份验证，写入密钥，然后在需要时读取它。

要进行实验，您可以使用如下命令以开发模式启动 OpenBao：

bao server -dev -dev-root-token-id=dev-only-token

在此模式下，OpenBao 会监听 8200 端口的 HTTP 请求，并生成一个具有完全访问权限的 root 令牌。这非常适合本地测试，但完全不适用于生产环境。下一步是使用您所使用的编程语言（例如，通过 curl 安装 Go 或 Bash）安装客户端库，并将相应的包导入到您的代码中。

在您的应用程序中，您可以通过指向服务器 URL 并配置身份验证方法来初始化客户端。在一个简单的示例中，您可以使用静态令牌（开发根令牌，或者在更实际的环境中使用服务令牌），但在生产环境中，通常会使用Kubernetes 身份验证、Approle、OIDC 或 LDAP等方式进行身份验证，因此应用程序中不会隐藏任何硬编码的密钥。

要存储典型的密钥（例如数据库访问密码），您可以使用KV v2引擎，通过调用 API 或客户端库，发送键值对以及必要的元数据。在您选择的路径（例如secret/data/app/backend）中，您可以存储类似password: "OpenBao123"这样的键值对。如果操作成功，应用程序将收到确认信息，并且密钥将被安全地存储在密钥库中。

当应用程序需要使用该凭据时，它会对同一路径执行读取操作，从 OpenBao 获取响应，提取密钥值（例如密码），并将其存储在内存中，而不会将其写入磁盘或记录到日志中。如果一切顺利，读取到的密钥应该与最初存储的密钥完全一致。

对于更高级的环境，OpenBao 提供Transit（加密和解密即服务）、PKI（证书颁发）、数据库（MySQL、PostgreSQL 等）动态密钥引擎或 SSH 证书颁发机构等引擎，此外还与 Kubernetes、Terraform、Ansible、公有云、Consul 和其他基础设施组件紧密集成。

开源生态系统中的密码库和密钥概述

OpenBao并非孤立存在；它是庞大的密码库和密钥管理生态系统的一部分，每个系统都有其独特的实现方式。了解这一生态系统有助于您确定OpenBao在您的业务中应扮演的角色，以及哪些其他组件可以与之互补。

如果我们讨论的是纯粹的“人为”密码（用户登录、面板访问权限等），那么有些工具因其简洁性而脱颖而出：

• KeePassXC.kdbx 加密文件，无需服务器或数据库。通过将文件放置在共享资源（Nextcloud、Samba、Syncthing 等）上进行共享。它非常适合用作入口点或 后备 离线使用，与浏览器和移动应用程序集成，支持 YubiKey 和 TOTP，且基础设施零复杂性。
• 金库守卫：用 Rust 重新实现的 Bitwarden 服务器 自托管 轻量级。它运行在单个 Docker 容器中，内存占用极低，并且无需额外费用即可解锁 Bitwarden 企业版功能（组织、收藏集、群组）。它与官方 Bitwarden 客户端完全兼容。
• 帕洛克这款管理工具拥有现代且简洁的界面，专为小团队共享密钥而设计，并提供端到端加密。它支持使用 Docker Compose 进行自托管，并且面向那些优先考虑用户体验而非传统企业集成复杂性的团队。
• Bitwarden 自托管官方它可能是经过最多审计的开源文件管理器，拥有高度完善的用户体验。虽然它比 Vaultwarden 需要更多资源，但它提供企业级单点登录 (SSO)、敏感信息安全管理 (SCIM)、LDAP/AD 集成以及高级策略，因此非常适合那些合规性和官方支持比易用性更重要的场景。

对于需要更精细控制凭证共享的团队，可以采用以下解决方案：

• Passbolt 社区版它以团队为中心，采用基于 OpenPGP 的端到端加密，私钥始终保留在用户设备内。它支持高度精细权限的密码共享，拥有完全免费的社区版，并且完全符合 GDPR 和欧洲法规。
• Psono 社区版它专为企业设计，提供多级加密（客户端 + TLS + 存储）、多因素身份验证 (MFA)、安全报告，并集成了 LDAP、SAML 和 OIDC。它还允许您在密钥更改时定义 HTTP 回调，非常适合自动化重置或部署。
• 团队通行证这是一个协作式的 PHP 和 MySQL 管理工具，如果您已经拥有这套技术栈，它将非常实用。它提供带有详细角色和权限的文件夹结构、加密的离线导出功能以及用户操作审计，尽管它的界面略显过时。

回顾应用秘籍，显然有一些项目可以与 OpenBao 相媲美：

• 英菲西卡尔麻省理工学院的平台专为 DevOps 和 Kubernetes 设计，原生支持数十种环境（Terraform、Ansible、GitHub Actions、AWS 等）。它涵盖应用程序密钥管理、PKI、凭证扫描和泄漏预防，并采用基于云的模型。 自托管 或混合型。
• 相一款现代化的密钥管理工具，拥有简洁美观的用户界面和以开发者为中心的设计理念。它为每个环境（开发/测试/生产）提供端到端加密，并可与 Kubernetes、GitHub Actions、Vercel 和 Docker 集成。部分企业级功能（SAML/OIDC）需要许可证。
• Cyber​​Ark Conjur OSS这是一个高度面向企业的平台，专注于“策略即代码”、细粒度的基于角色的访问控制 (RBAC) 以及针对工作负载（Kubernetes、AWS IAM、OIDC）的原生身份验证。开源软件 (OSS) 版本提供核心功能和软件开发工具包 (SDK)；高可用性、Web 用户界面和审计流功能则仅限企业版使用。

还有一些工具的设计理念截然不同，但可以作为补充：

• AliasVault密码管理器 隐私优先 它集成了一个邮件服务器，可以为每个网站生成备用身份（用户名、邮箱、密码）。它是完全自托管的，并使用 .NET + Blazor 编写。
• 密码存储 (通过）：遵循 Unix 标准。每个密码都是一个加密的 .gpg 文件，使用 Git 进行版本控制并组织到目录中，允许通过在配置中添加 GPG 公钥来共享密钥。无需服务器，且具有最大的可审计性，但学习曲线较为陡峭。
• 少通无状态范式。它不维护加密库，而是根据主密码和域名/登录名在本地重新生成每个密码，无需同步。这对于减少存储敏感数据的表面积非常有用。

最后，需要注意的是，虽然许多公司将密码存储委托给高度安全的远程服务，但有些组织更倾向于将密码库保存在本地，不接入互联网或仅限制访问权限。这样做虽然便于控制，但也需要密切监控安全更新：如果发现可利用的漏洞并迅速修复，则存储公司所有密码的密码库可能会遭到入侵。

OpenBao 作为安全内部平台的关键组件

在现代基于 Kubernetes 和 GitOps 的平台中，OpenBao 通常与其他组件（例如Keycloak、Kong 或 API 网关）、监控和可观测性系统以及使用 Terraform/OpenTofu 定义的基础设施层共存。平台专家（SRE）的职责正是确保开发人员能够以最简便的方式使用 OpenBao，同时确保其安全性。

这种“理想路径”是指在 Kubernetes（GKE 或其他集群）上部署服务，并使用 Argo CD 管理清单文件，然后通过自动身份验证（例如，Kubernetes 的身份验证方法，该方法将 ServiceAccount 映射到策略）从 OpenBao 获取其密钥。这样，开发人员无需担心凭据的存储或轮换方式，只需声明应用程序所需的权限即可。

在这种情况下，一支拥有Python 和 Go经验的团队可以同时开发基础设施和业务服务，并构建小型运维工具或控制器，以实现 OpenBao 策略、角色或引擎的自动化管理。这种模式将平台定位为“赋能者”，弥合了开发需求与安全和合规要求之间的差距。

此外，OpenBao 非常适合零信任安全架构，在这种架构中，从一开始就不假定任何事物或任何人是可信的。每个 API 请求、每个 Kubernetes 工作负载或每个 CI/CD 流水线都经过显式身份验证和授权，理想情况下使用带有 TTL 的短身份和密钥，从而降低泄露或特定时间点攻击的影响。

从全局来看——从 OpenBao 作为 Vault 的一个分支诞生，到它与 Linux 基金会的合作，再到它与 Kubernetes、GitOps 以及其他开源密钥库和密码管理器的集成——很明显，在寻求集中式、可扩展且真正开放的密钥管理方案时，它已成为一个非常可靠的选择。如果密钥的密封/解封策略设计完善，策略和配置以代码形式进行版本控制，并辅以良好的更新和审计实践，OpenBao 完全可以成为企业密钥安全的基石。