2 篇博文含有标签「云原生」

云原生技术体系与最佳实践

OpenBao 全景解析：从零到生产的开源密钥管理实战

2026年4月9日 · 阅读需 36 分钟

雨落无声，代码成诗 —— 致力于技术与艺术的极致平衡

"The best secret is one that is never exposed — OpenBao keeps it that way."

在现代云原生架构中，密钥管理（Secrets Management） 是安全基础设施的核心。数据库密码、API Key、TLS 证书、SSH 密钥……这些敏感信息散落在环境变量、配置文件、CI/CD Pipeline 中，成为攻击者的首要目标。

OpenBao 是 HashiCorp Vault 的 开源分叉（Fork），由 Linux Foundation 旗下的 LF Edge 项目托管，采用 MPL-2.0 许可证，完全开源、社区驱动。它继承了 Vault 强大的密钥管理能力，同时摆脱了商业许可变更的风险，是生产环境中管理密钥的理想选择。

本文将从零开始，由浅入深地带你全面掌握 OpenBao 的核心概念、安装配置、实战操作，直到生产级部署与运维。

一、OpenBao 是什么？

1.1 项目背景与定位

2023 年 8 月，HashiCorp 将 Vault 等核心产品从 MPL-2.0 许可证转为 BSL（Business Source License），限制竞争性使用。作为回应，社区发起了 OpenBao 项目，旨在维护一个完全开源的 Vault 替代品。

对比项	HashiCorp Vault	OpenBao
许可证	BSL 1.1（限制竞争使用）	MPL-2.0（真正开源）
治理	HashiCorp 公司主导	Linux Foundation / LF Edge 社区治理
API 兼容性	-	与 Vault API 高度兼容
CLI 命令	`vault`	`bao`
当前版本	1.x	2.5.x
定位	企业级密钥管理	社区驱动的开源密钥管理

1.2 核心能力概览

OpenBao 提供以下核心能力：

1.3 核心术语速查

在深入之前，先熟悉这些核心术语：

术语	说明
Secret Engine	存储、生成或加密数据的插件化组件，通过路径挂载（如 `secret/`、`database/`、`pki/`）
Auth Method	身份认证方式，验证用户/应用身份后颁发 Token
Token	认证成功后获得的凭证，携带策略信息，用于后续 API 调用
Policy	ACL 策略，定义 Token 对特定路径的权限（read / create / update / delete / list）
Lease	密钥的有效期，到期后自动撤销。可续租（renew）或主动撤销（revoke）
Seal / Unseal	OpenBao 的加密保护机制。启动时为 Sealed 状态，需提供 Unseal Key 才能解密数据
Barrier	加密屏障，所有写入存储的数据都经过 Barrier 加密
Root Key	加密 Keyring 的主密钥，由 Unseal Key 保护
Integrated Storage	内置的 Raft 共识存储后端，无需外部依赖

二、架构深度解析

2.1 整体架构

OpenBao 的架构可以分为以下几个层次：

2.2 加密屏障（Barrier）工作原理

OpenBao 的安全核心是多层加密架构。理解这个加密链非常重要：

关键设计

Unseal Key 不存储在任何地方 — 它由操作员持有（Shamir 分片分散在多人手中），或由外部 KMS/HSM 托管。
Root Key 加密存储 — 即使攻击者获取了存储后端的全部数据，没有 Unseal Key 也无法解密。
Encryption Key 支持轮换 — 可以在不停机的情况下定期轮换加密密钥，旧密钥保留在 Keyring 中用于解密历史数据。

2.3 请求处理流程

当客户端发起一个读取密钥的请求时，OpenBao 内部的处理流程如下：

三、安装与快速上手

3.1 安装方式

OpenBao 提供多种安装方式，以下按推荐顺序列出：

macOS（Homebrew）

# 安装
brew install openbao

# 验证
bao version
# OpenBao v2.5.x ...

Linux（包管理器）

# Arch Linux
pacman -Sy openbao

# Fedora / RHEL（需先启用 EPEL）
dnf install -y epel-release
dnf install -y openbao

# Debian / Ubuntu（使用官方仓库）
# 从 https://openbao.org/downloads/ 下载 .deb 包
wget https://github.com/openbao/openbao/releases/download/v2.5.0/bao_2.5.0_linux_amd64.deb
sudo dpkg -i bao_2.5.0_linux_amd64.deb

Docker 容器

# 支持三个镜像仓库
docker pull ghcr.io/openbao/openbao:latest
docker pull quay.io/openbao/openbao:latest
docker pull docker.io/openbao/openbao:latest

# 快速启动 Dev 模式
docker run --rm -p 8200:8200 \
  --memory-swappiness=0 \
  --name openbao-dev \
  ghcr.io/openbao/openbao:latest server -dev

安全加固提醒

安装后建议进行以下加固措施：

禁用 Swap：防止密钥数据被写入持久化交换空间。Linux 上 systemd 服务文件默认设置 MemorySwapMax=0。
Docker 启动时：添加 --memory-swappiness=0 标志。
macOS：默认 Swap 已加密，无需额外处理。

从源码编译

# 需要 Go 环境
mkdir -p $GOPATH/src/github.com/openbao && cd $_
git clone https://github.com/openbao/openbao.git
cd openbao
make bootstrap  # 下载依赖
make dev         # 编译 bao 二进制到 ./bin/

3.2 Dev 模式快速体验

Dev 模式是学习和测试的最佳起点。它以内存存储、自动 Unseal、预配置 Root Token 的方式启动，绝不能用于生产环境。

# 启动 Dev Server
bao server -dev

# 输出示例：
# ==> OpenBao server configuration:
#              Api Address: http://127.0.0.1:8200
#                      Cgo: disabled
#          Cluster Address: https://127.0.0.1:8201
#               Listener 1: tcp (addr: "127.0.0.1:8200", ...)
#                Log Level: info
#                    Mlock: supported: false, enabled: false
#            Recovery Mode: false
#                  Storage: inmem
#                  Version: OpenBao v2.5.x
#
# WARNING! dev mode is enabled! In this mode, OpenBao runs entirely
# in-memory. Data is lost on restart!
#
# Root Token: hvs.xxxxxxxxxxxxxxxxxxxxxxxx

在另一个终端中配置环境变量并开始操作：

# 设置环境变量
export BAO_ADDR='http://127.0.0.1:8200'
export BAO_TOKEN='hvs.xxxxxxxxxxxxxxxxxxxxxxxx'  # 使用上面输出的 Root Token

# 验证服务器状态
bao status

3.3 第一个 Secret：KV 引擎实战

KV（Key-Value）Secret Engine 是最基础的密钥存储引擎。Dev 模式下默认启用了 KV v2 引擎，挂载在 secret/ 路径。

# ==========================================
# 写入密钥
# ==========================================
bao kv put secret/myapp/config \
  db_host="postgres.prod.internal" \
  db_port="5432" \
  db_user="app_user" \
  db_password="S3cur3P@ssw0rd!"

# 输出：
# ======= Secret Path =======
# secret/data/myapp/config
#
# ======= Metadata =======
# Key                Value
# ---                -----
# created_time       2026-04-09T11:00:00.000000Z
# custom_metadata    <nil>
# deletion_time      n/a
# destroyed          false
# version            1

# ==========================================
# 读取密钥
# ==========================================
bao kv get secret/myapp/config

# 输出：
# ======= Secret Path =======
# secret/data/myapp/config
#
# ======= Metadata =======
# Key                Value
# ---                -----
# created_time       2026-04-09T11:00:00.000000Z
# version            1
#
# ====== Data ======
# Key             Value
# ---             -----
# db_host         postgres.prod.internal
# db_port         5432
# db_user         app_user
# db_password     S3cur3P@ssw0rd!

# ==========================================
# 读取特定字段
# ==========================================
bao kv get -field=db_password secret/myapp/config
# S3cur3P@ssw0rd!

# ==========================================
# JSON 格式输出（用于脚本/程序）
# ==========================================
bao kv get -format=json secret/myapp/config | jq '.data.data'

# ==========================================
# 更新密钥（创建新版本）
# ==========================================
bao kv put secret/myapp/config \
  db_host="postgres.prod.internal" \
  db_port="5432" \
  db_user="app_user" \
  db_password="N3wS3cur3P@ss!"
# 现在 version = 2

# ==========================================
# 读取历史版本
# ==========================================
bao kv get -version=1 secret/myapp/config

# ==========================================
# 列出所有密钥路径
# ==========================================
bao kv list secret/myapp/

# ==========================================
# 删除密钥（软删除，可恢复）
# ==========================================
bao kv delete secret/myapp/config

# ==========================================
# 恢复已删除的密钥
# ==========================================
bao kv undelete -versions=2 secret/myapp/config

# ==========================================
# 永久销毁指定版本（不可恢复）
# ==========================================
bao kv destroy -versions=1 secret/myapp/config

KV v1 vs KV v2

特性	KV v1	KV v2
版本控制	❌ 不支持	✅ 支持（每次写入创建新版本）
软删除	❌ 不支持	✅ 支持（可恢复）
元数据	❌ 不支持	✅ 支持（created_time、custom_metadata）
Check-and-Set	❌ 不支持	✅ 支持（CAS，防止并发写入覆盖）
路径前缀	`secret/<path>`	`secret/data/<path>`（API 路径）
推荐使用	简单场景	生产环境推荐

3.4 HTTP API 直接调用

除了 CLI，OpenBao 的所有操作都可以通过 HTTP API 完成：

# 写入密钥 (KV v2)
curl -s \
  --header "X-Vault-Token: $BAO_TOKEN" \
  --request POST \
  --data '{
    "data": {
      "api_key": "sk-abc123def456",
      "api_secret": "super-secret-value"
    }
  }' \
  $BAO_ADDR/v1/secret/data/myapp/api-keys | jq

# 读取密钥
curl -s \
  --header "X-Vault-Token: $BAO_TOKEN" \
  $BAO_ADDR/v1/secret/data/myapp/api-keys | jq '.data.data'

# 查看服务器状态
curl -s $BAO_ADDR/v1/sys/health | jq

四、Secret Engines 深度解析

Secret Engine 是 OpenBao 的核心组件，它们可以存储、生成或加密数据。每个引擎通过路径挂载来隔离，这意味着挂载在 database/ 路径的引擎和挂载在 secret/ 路径的引擎互不影响。

4.1 引擎全景

引擎	类型	用途	典型场景
KV	存储	键值对存储	应用配置、API Key、凭证
Database	动态	动态生成数据库凭证	MySQL、PostgreSQL、MongoDB 临时账号
PKI	动态	签发 X.509 证书	内部 TLS 证书、mTLS
Transit	加密	加密即服务（EaaS）	数据加密/解密/签名，无需管理密钥
SSH	动态	SSH 密钥/证书签发	服务器 SSH 访问控制
TOTP	动态	生成/验证 TOTP 码	双因素认证
Transform	加密	数据转换（FPE/掩码）	信用卡号、身份证号脱敏

4.2 动态密钥：Database 引擎实战

动态密钥是 OpenBao 最强大的特性之一 — 按需生成有时效性的数据库凭证，到期自动撤销。

# ==========================================
# 1. 启用 Database 引擎
# ==========================================
bao secrets enable database

# ==========================================
# 2. 配置 PostgreSQL 连接
# ==========================================
bao write database/config/my-postgresql-db \
  plugin_name="postgresql-database-plugin" \
  allowed_roles="readonly,readwrite" \
  connection_url="postgresql://{{username}}:{{password}}@postgres.internal:5432/myapp?sslmode=require" \
  username="vault_admin" \
  password="vault_admin_password"

# ==========================================
# 3. 创建只读角色（动态生成的用户只有 SELECT 权限）
# ==========================================
bao write database/roles/readonly \
  db_name="my-postgresql-db" \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
    GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  revocation_statements="DROP ROLE IF EXISTS \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="24h"

# ==========================================
# 4. 创建读写角色
# ==========================================
bao write database/roles/readwrite \
  db_name="my-postgresql-db" \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
    GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  revocation_statements="DROP ROLE IF EXISTS \"{{name}}\";" \
  default_ttl="30m" \
  max_ttl="2h"

# ==========================================
# 5. 动态获取凭证
# ==========================================
bao read database/creds/readonly

# 输出：
# Key                Value
# ---                -----
# lease_id           database/creds/readonly/abcd1234...
# lease_duration     1h
# lease_renewable    true
# password           A1a-xxxxxxxxxxxxxxxxx
# username           v-token-readonly-xxxxxxxxx

# ==========================================
# 6. 续租 Lease
# ==========================================
bao lease renew database/creds/readonly/abcd1234...

# ==========================================
# 7. 手动撤销（立即删除数据库用户）
# ==========================================
bao lease revoke database/creds/readonly/abcd1234...

动态密钥最佳实践

始终设置合理的 TTL — default_ttl 建议 ≤ 1 小时，max_ttl 建议 ≤ 24 小时。
应用侧要处理凭证续租 — 在 Lease 到期前主动 renew，或使用 OpenBao Agent 自动续租。
轮换初始管理员密码 — 配置完数据库连接后，执行 bao write -force database/rotate-root/my-postgresql-db 轮换管理员密码，阻止人工直接登录数据库。

4.3 PKI 引擎：内部 TLS 证书管理

PKI 引擎可以让 OpenBao 成为你的内部 CA（Certificate Authority），自动签发和管理 TLS 证书。

# ==========================================
# 1. 启用 PKI 引擎（Root CA）
# ==========================================
bao secrets enable pki

# 设置最大 TTL 为 10 年
bao secrets tune -max-lease-ttl=87600h pki

# 生成 Root CA 证书
bao write -field=certificate pki/root/generate/internal \
  common_name="My Organization Root CA" \
  issuer_name="root-2026" \
  ttl=87600h > root_ca.crt

# ==========================================
# 2. 启用中间 CA（Intermediate CA）
# ==========================================
bao secrets enable -path=pki_int pki

bao secrets tune -max-lease-ttl=43800h pki_int

# 生成 CSR
bao write -field=csr pki_int/intermediate/generate/internal \
  common_name="My Organization Intermediate CA" \
  issuer_name="intermediate-2026" > pki_intermediate.csr

# 用 Root CA 签名
bao write -field=certificate pki/root/sign-intermediate \
  csr=@pki_intermediate.csr \
  format=pem_bundle \
  ttl=43800h > intermediate_ca.crt

# 导入签名后的证书
bao write pki_int/intermediate/set-signed \
  certificate=@intermediate_ca.crt

# ==========================================
# 3. 创建角色（定义可签发的证书规范）
# ==========================================
bao write pki_int/roles/internal-service \
  allowed_domains="internal.mycompany.com,svc.cluster.local" \
  allow_subdomains=true \
  max_ttl="720h" \
  key_type="ec" \
  key_bits=256

# ==========================================
# 4. 签发证书
# ==========================================
bao write pki_int/issue/internal-service \
  common_name="api.internal.mycompany.com" \
  ttl="72h"

# 输出包含：
# - certificate    (服务器证书)
# - issuing_ca     (中间 CA 证书)
# - private_key    (私钥，只在此刻返回！)
# - serial_number  (证书序列号)

4.4 Transit 引擎：加密即服务（EaaS）

Transit 引擎提供加密即服务，应用不需要管理加密密钥，只需调用 API 即可完成加密/解密/签名操作。数据不会存储在 OpenBao 中，Transit 只负责加密操作。

# 启用 Transit 引擎
bao secrets enable transit

# 创建加密密钥
bao write -f transit/keys/my-app-key

# 加密数据（输入必须 base64 编码）
bao write transit/encrypt/my-app-key \
  plaintext=$(echo -n "my-secret-data" | base64)

# 输出：
# Key            Value
# ---            -----
# ciphertext     vault:v1:xxxxxxxxxxxxxxxxxxxxxx
# key_version    1

# 解密数据
bao write transit/decrypt/my-app-key \
  ciphertext="vault:v1:xxxxxxxxxxxxxxxxxxxxxx"

# 输出中的 plaintext 需要 base64 解码
# echo "base64-output" | base64 -d
# my-secret-data

# 密钥轮换
bao write -f transit/keys/my-app-key/rotate

# 重新加密（使用新密钥版本加密已有密文）
bao write transit/rewrap/my-app-key \
  ciphertext="vault:v1:xxxxxxxxxxxxxxxxxxxxxx"
# ciphertext 变为 vault:v2:...

五、认证与授权

5.1 Auth Methods 概览

OpenBao 支持多种认证方式，以适应不同场景：

Auth Method	适用对象	说明
Token	所有场景	核心认证方式，所有其他方式最终都返回 Token
UserPass	人类用户	用户名/密码认证，适合开发和测试
AppRole	应用/服务	基于 Role ID + Secret ID 的双因素认证
Kubernetes	K8s Pod	使用 Service Account Token 自动认证
LDAP	企业用户	集成企业目录服务
JWT/OIDC	SSO 用户	集成 Okta、Auth0、Google 等身份提供商
TLS Certificates	mTLS 场景	使用客户端证书认证

5.2 AppRole 认证实战（推荐用于应用）

AppRole 是应用和服务最推荐的认证方式。它采用双因素模型：Role ID（公开部分） + Secret ID（敏感部分）。

# ==========================================
# 1. 启用 AppRole
# ==========================================
bao auth enable approle

# ==========================================
# 2. 创建角色
# ==========================================
bao write auth/approle/role/my-app \
  token_policies="my-app-policy" \
  token_ttl=1h \
  token_max_ttl=4h \
  secret_id_ttl=10m \
  secret_id_num_uses=1  # Secret ID 只能使用一次

# ==========================================
# 3. 获取 Role ID（可以嵌入配置文件或环境变量）
# ==========================================
bao read auth/approle/role/my-app/role-id
# role_id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

# ==========================================
# 4. 生成 Secret ID（应通过安全通道传递给应用）
# ==========================================
bao write -f auth/approle/role/my-app/secret-id
# secret_id: yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy

# ==========================================
# 5. 应用侧：使用 Role ID + Secret ID 登录
# ==========================================
bao write auth/approle/login \
  role_id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \
  secret_id="yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"

# 输出：
# Key                     Value
# ---                     -----
# token                   hvs.CAESIXXXXXXXXXXXXXXXXXX
# token_accessor          xxxxxxxxxxxxxxxxxxxxxxxx
# token_duration          1h
# token_renewable         true
# token_policies          ["default" "my-app-policy"]

# ==========================================
# 6. 使用获取的 Token 读取密钥
# ==========================================
BAO_TOKEN=hvs.CAESIXXXXXXXXXXXXXXXXXX \
  bao kv get secret/myapp/config

5.3 Kubernetes 认证

在 Kubernetes 环境中，Pod 可以使用 Service Account Token 直接向 OpenBao 认证：

# 启用 Kubernetes Auth
bao auth enable kubernetes

# 配置 Kubernetes 集群信息
bao write auth/kubernetes/config \
  kubernetes_host="https://kubernetes.default.svc:443"

# 创建角色（绑定 Service Account 和 Namespace）
bao write auth/kubernetes/role/my-app \
  bound_service_account_names=my-app-sa \
  bound_service_account_namespaces=production \
  policies=my-app-policy \
  ttl=1h

5.4 Token 类型与层级

OpenBao 中有两种 Token 类型：

类型	说明	适用场景
Service Token	可续租、可撤销、有持久化存储的 Token	长期运行的服务
Batch Token	轻量级、不可续租、无持久化的 Token	高吞吐量的短期操作

Token 还有层级概念：

Root Token
  ├── Service Token A (policy: admin)
  │     ├── Service Token A1 (policy: readonly)
  │     └── Service Token A2 (policy: readwrite)
  └── Service Token B (policy: app)
        └── Batch Token B1 (policy: app)

Root Token 安全

Root Token 拥有一切权限，相当于 Linux 的 root 用户。
生产环境中，初始化完成后应立即撤销 Root Token：bao token revoke <root-token>
需要时可通过 bao operator generate-root 临时生成新的 Root Token（需要多个 Unseal Key 持有者共同授权）。

六、ACL 策略（Policies）

6.1 策略语法

策略定义了 Token 对特定路径的访问权限。OpenBao 采用白名单模式 — 未显式授予的权限一律拒绝。

# ================================================
# 文件：my-app-policy.hcl
# 描述：应用 my-app 的 ACL 策略
# ================================================

# 允许读取和列出应用配置
path "secret/data/myapp/*" {
  capabilities = ["read", "list"]
}

# 允许读取和更新特定路径
path "secret/data/myapp/config" {
  capabilities = ["create", "read", "update"]
}

# 允许获取数据库动态凭证
path "database/creds/readonly" {
  capabilities = ["read"]
}

# 允许续租和撤销自己的 Lease
path "sys/leases/renew" {
  capabilities = ["update"]
}

path "sys/leases/revoke" {
  capabilities = ["update"]
}

# 允许查看自己的 Token 信息
path "auth/token/lookup-self" {
  capabilities = ["read"]
}

# 允许续租自己的 Token
path "auth/token/renew-self" {
  capabilities = ["update"]
}

# 拒绝访问元数据（使用 deny 覆盖其他策略）
path "secret/metadata/*" {
  capabilities = ["deny"]
}

6.2 权限说明

Capability	说明	对应 HTTP 方法
`create`	创建新数据	`POST`
`read`	读取数据	`GET`
`update`	更新已有数据	`POST/PUT`
`delete`	删除数据	`DELETE`
`list`	列出路径下的键	`LIST`
`sudo`	允许访问需要 root 权限的路径	-
`deny`	显式拒绝（最高优先级）	-

6.3 策略管理

# 创建/更新策略
bao policy write my-app-policy my-app-policy.hcl

# 查看策略列表
bao policy list

# 查看策略内容
bao policy read my-app-policy

# 删除策略
bao policy delete my-app-policy

# 为已有 Token 关联策略
bao token create -policy="my-app-policy" -ttl=2h

6.4 策略模板（参数化策略）

OpenBao 支持在策略中使用模板变量，实现基于身份的动态权限：

# 每个用户只能访问自己的密钥空间
path "secret/data/users/{{identity.entity.name}}/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

# 每个团队只能管理自己的密钥
path "secret/data/teams/{{identity.groups.names.*.id}}/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

七、Seal / Unseal 机制详解

7.1 Shamir 分片（默认）

OpenBao 默认使用 Shamir's Secret Sharing 算法将 Unseal Key 分割为多个分片。只需要一定数量（阈值）的分片即可重建 Unseal Key。

# 初始化（设置 5 个分片，阈值 3）
bao operator init -key-shares=5 -key-threshold=3

# 输出示例：
# Unseal Key 1: abc...
# Unseal Key 2: def...
# Unseal Key 3: ghi...
# Unseal Key 4: jkl...
# Unseal Key 5: mno...
#
# Initial Root Token: hvs.xxxxxxxxxx
#
# 请将这些 Key 分发给不同的人！

# Unseal 过程（需要提供 3 个 Key）
bao operator unseal  # 输入 Key 1
# Sealed: true, Progress: 1/3

bao operator unseal  # 输入 Key 2
# Sealed: true, Progress: 2/3

bao operator unseal  # 输入 Key 3
# Sealed: false  ← Unseal 成功！

分片分发最佳实践

场景	分片数	阈值	说明
开发/测试	1	1	单人即可 Unseal
小团队	3	2	至少 2 人同时在场
生产环境	5	3	容忍 2 个分片丢失，需要 3 人同时授权
企业级	7	4	高安全性要求

7.2 Auto Unseal（推荐用于生产）

Shamir 分片的手动 Unseal 过程增加了运维复杂度（每次重启都需要收集足够的 Key）。Auto Unseal 将 Unseal Key 的保管委托给外部的 KMS 或 HSM，实现自动解封。

支持的 Auto Unseal Provider：

Provider	配置块名称	说明
AWS KMS	`seal "awskms"`	AWS Key Management Service
GCP Cloud KMS	`seal "gcpckms"`	Google Cloud KMS
Azure Key Vault	`seal "azurekeyvault"`	Azure 密钥保管库
AliCloud KMS	`seal "alicloudkms"`	阿里云密钥管理服务
OCI KMS	`seal "ocikms"`	Oracle Cloud KMS
HSM (PKCS#11)	`seal "pkcs11"`	硬件安全模块
Transit	`seal "transit"`	使用另一个 OpenBao 实例

AWS KMS 配置示例：

seal "awskms" {
  region     = "ap-southeast-1"
  kms_key_id = "arn:aws:kms:ap-southeast-1:123456789:key/abcd-1234-..."

  # 可选：指定 AWS 凭证（推荐使用 IAM Role）
  # access_key = "..."
  # secret_key = "..."
}

Auto Unseal 的风险

使用 Auto Unseal 会创建 OpenBao 对外部 KMS 的生命周期依赖：

如果 KMS 密钥不可用（如 AWS 服务故障），OpenBao 无法启动。
如果 KMS 密钥被永久删除，OpenBao 数据将永远无法恢复，即使从备份恢复也不行。
建议：使用 AWS SCP（Service Control Policies）等机制保护 KMS 密钥不被删除。

7.3 Seal 迁移

在不同 Seal 类型之间迁移（如从 Shamir 迁移到 Auto Unseal）是可能的，但需要停机操作：

八、生产级部署

8.1 生产配置文件

以下是一个完整的生产级 OpenBao 配置文件，使用 Integrated Storage（Raft）：

# ================================================
# /etc/openbao/config.hcl - 生产级配置
# ================================================

# --- 集群标识 ---
cluster_name = "prod-openbao-cluster"

# --- 网络地址 ---
# API 地址：客户端访问地址
api_addr = "https://openbao.mycompany.com:8200"
# 集群通信地址：节点间通信
cluster_addr = "https://10.0.1.10:8201"

# --- Web UI ---
ui = true

# --- 日志 ---
log_level = "info"
log_format = "json"
log_file = "/var/log/openbao/openbao.log"
log_rotate_duration = "24h"
log_rotate_max_files = 30

# --- Listener (TLS) ---
listener "tcp" {
  address       = "0.0.0.0:8200"
  cluster_address = "0.0.0.0:8201"

  # TLS 配置（生产环境必须启用）
  tls_cert_file = "/etc/openbao/tls/server.crt"
  tls_key_file  = "/etc/openbao/tls/server.key"
  tls_client_ca_file = "/etc/openbao/tls/ca.crt"

  # TLS 最低版本
  tls_min_version = "tls12"

  # 禁用弱密码套件
  tls_cipher_suites = "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"

  # 请求限制
  max_request_duration = "90s"
  max_request_size = 33554432  # 32MB
}

# --- Storage (Raft / Integrated Storage) ---
storage "raft" {
  path    = "/opt/openbao/data"
  node_id = "node-1"

  # 性能调优
  performance_multiplier = 1  # 生产环境设为 1（低延迟调优）

  # Autopilot 配置（自动管理集群成员）
  autopilot {
    cleanup_dead_servers = true
    dead_server_last_contact_threshold = "24h"
    min_quorum = 3
  }

  # 集群对端节点
  retry_join {
    leader_api_addr = "https://10.0.1.11:8200"
    leader_ca_cert_file = "/etc/openbao/tls/ca.crt"
  }
  retry_join {
    leader_api_addr = "https://10.0.1.12:8200"
    leader_ca_cert_file = "/etc/openbao/tls/ca.crt"
  }
}

# --- Auto Unseal (可选，推荐) ---
seal "awskms" {
  region     = "ap-southeast-1"
  kms_key_id = "arn:aws:kms:ap-southeast-1:123456789:key/abcd-1234-..."
}

# --- Telemetry （可观测性）---
telemetry {
  # Prometheus 指标端点
  prometheus_retention_time = "24h"
  disable_hostname = true

  # StatsD（可选）
  # statsd_address = "statsd.internal:8125"
}

# --- Lease 管理 ---
default_lease_ttl = "768h"    # 默认 32 天
max_lease_ttl = "768h"        # 最大 32 天

# --- 审计 (在初始化后通过 API 启用) ---
# bao audit enable file file_path=/var/log/openbao/audit.log

8.2 systemd 服务配置

# /etc/systemd/system/openbao.service
[Unit]
Description=OpenBao - A tool for managing secrets
Documentation=https://openbao.org/docs/
Requires=network-online.target
After=network-online.target
ConditionFileNotEmpty=/etc/openbao/config.hcl
StartLimitIntervalSec=60
StartLimitBurst=3

[Service]
Type=notify
User=openbao
Group=openbao
ProtectSystem=full
ProtectHome=read-only
PrivateTmp=yes
PrivateDevices=yes
SecureBits=keep-caps
AmbientCapabilities=CAP_IPC_LOCK
NoNewPrivileges=yes
ExecStart=/usr/bin/bao server -config=/etc/openbao/config.hcl
ExecReload=/bin/kill --signal HUP $MAINPID
KillMode=process
KillSignal=SIGINT
Restart=on-failure
RestartSec=5
TimeoutStopSec=30
LimitNOFILE=65536
LimitMEMLOCK=infinity
MemorySwapMax=0

[Install]
WantedBy=multi-user.target

8.3 初始化与首次启动

# 1. 创建数据目录
sudo mkdir -p /opt/openbao/data
sudo chown openbao:openbao /opt/openbao/data

# 2. TLS 证书准备（假设已有证书）
sudo mkdir -p /etc/openbao/tls
sudo cp server.crt server.key ca.crt /etc/openbao/tls/
sudo chown openbao:openbao /etc/openbao/tls/*
sudo chmod 600 /etc/openbao/tls/server.key

# 3. 启动服务
sudo systemctl enable openbao
sudo systemctl start openbao

# 4. 初始化（仅首次）
export BAO_ADDR='https://openbao.mycompany.com:8200'
export BAO_CACERT='/etc/openbao/tls/ca.crt'

bao operator init \
  -key-shares=5 \
  -key-threshold=3

# ⚠️ 安全保存输出的 Unseal Key 和 Root Token！

# 5. Unseal
bao operator unseal  # 输入 Key 1
bao operator unseal  # 输入 Key 2
bao operator unseal  # 输入 Key 3

# 6. 验证
bao status

# 7. 登录
bao login $ROOT_TOKEN

# 8. 启用审计日志（生产必备）
bao audit enable file file_path=/var/log/openbao/audit.log

# 9. 撤销 Root Token（安全最佳实践）
bao token revoke $ROOT_TOKEN

九、高可用（HA）集群

9.1 Integrated Storage（Raft）HA 架构

OpenBao 推荐使用 Integrated Storage（基于 Raft 共识算法） 作为存储后端，它无需外部依赖（如 Consul），且内置 HA 能力。

9.2 集群节点配置

Node 1（Leader 候选）：

storage "raft" {
  path    = "/opt/openbao/data"
  node_id = "node-1"

  retry_join {
    leader_api_addr = "https://10.0.1.11:8200"
    leader_ca_cert_file = "/etc/openbao/tls/ca.crt"
  }
  retry_join {
    leader_api_addr = "https://10.0.1.12:8200"
    leader_ca_cert_file = "/etc/openbao/tls/ca.crt"
  }
}

Node 2 & 3（类似配置，修改 node_id 和 retry_join 节点列表）：

storage "raft" {
  path    = "/opt/openbao/data"
  node_id = "node-2"  # 或 node-3

  retry_join {
    leader_api_addr = "https://10.0.1.10:8200"
    leader_ca_cert_file = "/etc/openbao/tls/ca.crt"
  }
  retry_join {
    leader_api_addr = "https://10.0.1.12:8200"  # 或 10.0.1.11
    leader_ca_cert_file = "/etc/openbao/tls/ca.crt"
  }
}

9.3 加入集群

# 在 Node 2 和 Node 3 上执行
# 首先启动服务
sudo systemctl start openbao

# 然后 Unseal（每个节点都需要独立 Unseal）
bao operator unseal  # Key 1
bao operator unseal  # Key 2
bao operator unseal  # Key 3

# 检查 Raft 成员列表（在 Leader 节点上）
bao operator raft list-peers

# 输出：
# Node       Address            State       Voter
# ----       -------            -----       -----
# node-1     10.0.1.10:8201     leader      true
# node-2     10.0.1.11:8201     follower    true
# node-3     10.0.1.12:8201     follower    true

9.4 HA 运维操作

# 查看 Leader 信息
bao status
# HA Enabled: true
# HA Cluster: https://10.0.1.10:8201
# HA Mode:    active  (或 standby)

# 手动 Step Down（触发领导权转移）
bao operator step-down

# Raft 快照备份
bao operator raft snapshot save backup-$(date +%Y%m%d).snap

# Raft 快照恢复
bao operator raft snapshot restore backup-20260409.snap

# 移除失败的节点
bao operator raft remove-peer node-3

HA 集群最佳实践

节点数量：生产环境建议 3 或 5 个节点（奇数节点，满足 Raft 多数派要求）。
网络延迟：同 Region 部署，节点间延迟应 < 10ms。
负载均衡：所有节点都可以处理读请求；写请求会被自动转发到 Leader。
备份策略：每日自动执行 raft snapshot save，保存到安全的外部存储。
监控：关注 vault.raft.leader.lastContact 和 vault.raft.commitTime 指标。

十、审计日志

审计日志是安全合规的基础。OpenBao 支持三种审计设备：

10.1 启用审计

# 文件审计（最常用）
bao audit enable file file_path=/var/log/openbao/audit.log

# Syslog 审计
bao audit enable syslog tag="openbao" facility="AUTH"

# Socket 审计（发送到远程日志系统）
bao audit enable socket address="logserver.internal:9090" socket_type="tcp"

# 查看已启用的审计设备
bao audit list -detailed

10.2 审计日志格式

每条审计记录包含完整的请求和响应信息（敏感数据会被 HMAC 哈希处理）：

{
  "time": "2026-04-09T11:00:00.000000Z",
  "type": "response",
  "auth": {
    "client_token": "hmac-sha256:abcdef...",
    "accessor": "hmac-sha256:123456...",
    "display_name": "approle",
    "policies": ["default", "my-app-policy"],
    "token_type": "service"
  },
  "request": {
    "id": "request-uuid",
    "operation": "read",
    "path": "secret/data/myapp/config",
    "remote_address": "10.0.2.50"
  },
  "response": {
    "data": {
      "data": {
        "db_host": "hmac-sha256:xxxxxx...",
        "db_password": "hmac-sha256:yyyyyy..."
      }
    }
  }
}

审计安全性

必须至少启用一个审计设备。如果所有审计设备都失败，OpenBao 将拒绝处理任何请求，以确保不会出现未记录审计的操作。
审计日志中的敏感数据使用 HMAC-SHA256 哈希，无法逆向还原。但如果你知道原始值，可以通过 bao audit hash 命令计算哈希值进行比对。
建议将审计日志实时转发到集中式日志系统（如 ELK、Loki、Splunk）。

十一、Kubernetes 集成

11.1 Helm 部署 OpenBao

OpenBao 官方提供了 Helm Chart，可以方便地在 Kubernetes 上部署 HA 集群：

# 添加 Helm 仓库
helm repo add openbao https://openbao.github.io/openbao-helm
helm repo update

# 创建 values.yaml
cat <<EOF > openbao-values.yaml
global:
  enabled: true
  tlsDisable: false

server:
  image:
    repository: ghcr.io/openbao/openbao
    tag: "2.5.0"

  # HA 模式（3 副本）
  ha:
    enabled: true
    replicas: 3
    raft:
      enabled: true
      config: |
        ui = true

        listener "tcp" {
          address = "[::]:8200"
          cluster_address = "[::]:8201"
          tls_cert_file = "/vault/tls/tls.crt"
          tls_key_file = "/vault/tls/tls.key"
        }

        storage "raft" {
          path = "/vault/data"

          retry_join {
            leader_api_addr = "https://openbao-0.openbao-internal:8200"
            leader_ca_cert_file = "/vault/tls/ca.crt"
          }
          retry_join {
            leader_api_addr = "https://openbao-1.openbao-internal:8200"
            leader_ca_cert_file = "/vault/tls/ca.crt"
          }
          retry_join {
            leader_api_addr = "https://openbao-2.openbao-internal:8200"
            leader_ca_cert_file = "/vault/tls/ca.crt"
          }
        }

        service_registration "kubernetes" {}

  # 持久化存储
  dataStorage:
    enabled: true
    size: 10Gi
    storageClass: "gp3"

  # 资源限制
  resources:
    requests:
      cpu: 500m
      memory: 256Mi
    limits:
      cpu: 2000m
      memory: 1Gi

  # 审计日志存储
  auditStorage:
    enabled: true
    size: 5Gi

# Agent Injector（自动注入 sidecar）
injector:
  enabled: true
  replicas: 2
  resources:
    requests:
      cpu: 100m
      memory: 64Mi

# Web UI
ui:
  enabled: true
  serviceType: ClusterIP
EOF

# 部署
helm install openbao openbao/openbao \
  -n openbao --create-namespace \
  -f openbao-values.yaml

11.2 Agent Injector：自动为 Pod 注入密钥

OpenBao Agent Injector 是一个 Kubernetes Mutating Webhook，它通过注解（Annotations）为 Pod 自动注入 Sidecar，从 OpenBao 获取密钥并写入文件。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
      annotations:
        # ========================================
        # OpenBao Agent Injector 注解
        # ========================================
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "my-app"

        # 注入数据库凭证
        vault.hashicorp.com/agent-inject-secret-db-creds: "database/creds/readonly"
        vault.hashicorp.com/agent-inject-template-db-creds: |
          {{- with secret "database/creds/readonly" -}}
          DB_HOST=postgres.internal
          DB_PORT=5432
          DB_USER={{ .Data.username }}
          DB_PASSWORD={{ .Data.password }}
          {{- end }}

        # 注入应用配置
        vault.hashicorp.com/agent-inject-secret-app-config: "secret/data/myapp/config"
        vault.hashicorp.com/agent-inject-template-app-config: |
          {{- with secret "secret/data/myapp/config" -}}
          API_KEY={{ .Data.data.api_key }}
          API_SECRET={{ .Data.data.api_secret }}
          {{- end }}

    spec:
      serviceAccountName: my-app-sa
      containers:
        - name: my-app
          image: my-app:latest
          command: ["/bin/sh", "-c"]
          args:
            - |
              source /vault/secrets/db-creds
              source /vault/secrets/app-config
              exec ./my-app-binary
          ports:
            - containerPort: 8080

密钥将被注入到 Pod 的 /vault/secrets/ 目录下：

/vault/secrets/
├── db-creds       # 数据库凭证
└── app-config     # 应用配置

11.3 CSI Provider（另一种注入方式）

除了 Agent Injector，还可以使用 CSI（Container Storage Interface）Provider 将密钥作为卷挂载：

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  serviceAccountName: my-app-sa
  containers:
    - name: my-app
      image: my-app:latest
      volumeMounts:
        - name: secrets
          mountPath: "/mnt/secrets"
          readOnly: true
  volumes:
    - name: secrets
      csi:
        driver: secrets-store.csi.k8s.io
        readOnly: true
        volumeAttributes:
          secretProviderClass: "openbao-secrets"
---
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: openbao-secrets
spec:
  provider: vault # OpenBao 兼容 Vault CSI Provider
  parameters:
    roleName: "my-app"
    vaultAddress: "https://openbao.openbao.svc:8200"
    objects: |
      - objectName: "db-password"
        secretPath: "secret/data/myapp/config"
        secretKey: "db_password"

十二、OpenBao Agent / Proxy

12.1 Agent 模式

OpenBao Agent 是一个客户端守护进程，提供以下能力：

Auto Auth：自动认证并获取 Token
Caching：本地缓存 Token 和 Lease，减少对 Server 的请求
Templating：将密钥渲染到配置文件模板中
API Proxy：代理 API 请求，自动注入认证信息

# /etc/openbao/agent.hcl

# 如何认证
auto_auth {
  method "approle" {
    config = {
      role_id_file_path   = "/etc/openbao/role-id"
      secret_id_file_path = "/etc/openbao/secret-id"
      remove_secret_id_file_after_reading = true
    }
  }

  # 将 Token 保存到文件
  sink "file" {
    config = {
      path = "/tmp/openbao-token"
      mode = 0640
    }
  }
}

# 缓存配置
cache {
  use_auto_auth_token = true
}

# API 代理
listener "tcp" {
  address     = "127.0.0.1:8100"
  tls_disable = true
}

# 服务器连接
vault {
  address = "https://openbao.mycompany.com:8200"
  tls_ca_cert = "/etc/openbao/tls/ca.crt"
}

# 模板渲染
template {
  source      = "/etc/openbao/templates/db-config.tpl"
  destination = "/app/config/database.env"
  perms       = 0640
  command     = "systemctl reload my-app"  # 渲染后执行的命令
}

模板文件示例 (db-config.tpl)：

{{ with secret "database/creds/readonly" }}
DB_USER={{ .Data.username }}
DB_PASSWORD={{ .Data.password }}
{{ end }}
{{ with secret "secret/data/myapp/config" }}
API_KEY={{ .Data.data.api_key }}
{{ end }}

# 启动 Agent
bao agent -config=/etc/openbao/agent.hcl

12.2 Proxy 模式

OpenBao Proxy 与 Agent 类似，但专注于API 代理功能，不包含模板渲染。适合作为应用的 Sidecar 使用。

十三、运维与监控

13.1 关键监控指标

指标	说明	告警阈值
`vault.core.handle_request`	请求处理延迟	P99 > 500ms
`vault.barrier.get`	Barrier 读取延迟	P99 > 100ms
`vault.barrier.put`	Barrier 写入延迟	P99 > 200ms
`vault.raft.leader.lastContact`	Follower 到 Leader 的最后联系时间	> 500ms
`vault.raft.commitTime`	Raft 提交时间	P99 > 50ms
`vault.expire.num_leases`	当前活跃 Lease 数	根据容量规划
`vault.runtime.alloc_bytes`	内存分配量	接近 limits
`vault.core.unsealed`	是否已 Unseal	= 0 表示 Sealed

13.2 Prometheus 集成

# prometheus-scrape-config.yaml
scrape_configs:
  - job_name: "openbao"
    metrics_path: "/v1/sys/metrics"
    params:
      format: ["prometheus"]
    scheme: "https"
    tls_config:
      ca_file: "/etc/prometheus/openbao-ca.crt"
    authorization:
      credentials_file: "/etc/prometheus/openbao-token"
    static_configs:
      - targets:
          - "openbao-0.internal:8200"
          - "openbao-1.internal:8200"
          - "openbao-2.internal:8200"

13.3 备份与恢复策略

# ==========================================
# 自动备份脚本
# ==========================================
#!/bin/bash
# /opt/openbao/scripts/backup.sh

BACKUP_DIR="/opt/openbao/backups"
DATE=$(date +%Y%m%d-%H%M%S)
RETENTION_DAYS=30

# 创建快照
bao operator raft snapshot save "${BACKUP_DIR}/openbao-${DATE}.snap"

# 上传到对象存储（示例：AWS S3）
aws s3 cp "${BACKUP_DIR}/openbao-${DATE}.snap" \
  "s3://my-backups/openbao/openbao-${DATE}.snap" \
  --sse aws:kms

# 清理本地旧备份
find "${BACKUP_DIR}" -name "*.snap" -mtime +${RETENTION_DAYS} -delete

echo "[$(date)] Backup completed: openbao-${DATE}.snap"

# 添加到 crontab（每天凌晨 3 点备份）
echo "0 3 * * * /opt/openbao/scripts/backup.sh >> /var/log/openbao/backup.log 2>&1" \
  | crontab -

13.4 密钥轮换

# 轮换加密密钥（在线操作，不影响服务）
bao operator rotate

# 查看当前密钥信息
bao read sys/key-status
# Key              Value
# ---              -----
# install_time     2026-04-09T00:00:00Z
# term             2  # 密钥已轮换过 1 次

十四、应用集成模式

14.1 应用读取密钥的四种方式

方式	复杂度	适用场景	优缺点
直接 API	高	需要精细控制的应用	灵活但需自行管理 Token 生命周期
Agent	中	虚拟机/裸金属部署	自动认证+缓存+模板，推荐
K8s Injector	低	Kubernetes 环境	注解驱动，零代码侵入
CSI Provider	低	Kubernetes 环境	标准 Volume 接口

14.2 Go 应用集成示例

package main

import (
    "context"
    "fmt"
    "log"
    "time"

    vault "github.com/openbao/openbao/api/v2"
)

func main() {
    // 创建客户端
    config := vault.DefaultConfig()
    config.Address = "https://openbao.mycompany.com:8200"

    client, err := vault.NewClient(config)
    if err != nil {
        log.Fatalf("unable to initialize OpenBao client: %v", err)
    }

    // AppRole 登录
    resp, err := client.Logical().Write("auth/approle/login", map[string]interface{}{
        "role_id":   "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "secret_id": "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy",
    })
    if err != nil {
        log.Fatalf("unable to login: %v", err)
    }
    client.SetToken(resp.Auth.ClientToken)

    // 读取密钥
    secret, err := client.KVv2("secret").Get(context.Background(), "myapp/config")
    if err != nil {
        log.Fatalf("unable to read secret: %v", err)
    }

    dbHost := secret.Data["db_host"].(string)
    dbPassword := secret.Data["db_password"].(string)
    fmt.Printf("DB Host: %s\n", dbHost)
    fmt.Printf("DB Password: %s\n", dbPassword)

    // Token 续租（后台 goroutine）
    go func() {
        for {
            time.Sleep(30 * time.Minute)
            _, err := client.Auth().Token().RenewSelf(3600) // 续租 1 小时
            if err != nil {
                log.Printf("token renewal failed: %v", err)
            }
        }
    }()

    // ... 应用正常逻辑
    select {}
}

14.3 Python 应用集成示例

import hvac  # pip install hvac（兼容 OpenBao API）
import os
import time
import threading

class SecretsManager:
    """OpenBao 密钥管理封装"""

    def __init__(self):
        self.client = hvac.Client(
            url=os.environ.get('BAO_ADDR', 'https://openbao.mycompany.com:8200'),
            verify='/etc/openbao/tls/ca.crt'
        )
        self._login()
        self._start_renewal()

    def _login(self):
        """使用 AppRole 登录"""
        result = self.client.auth.approle.login(
            role_id=os.environ['BAO_ROLE_ID'],
            secret_id=os.environ['BAO_SECRET_ID']
        )
        self.client.token = result['auth']['client_token']
        self.lease_duration = result['auth']['lease_duration']

    def get_secret(self, path: str, key: str = None) -> dict | str:
        """读取 KV v2 密钥"""
        response = self.client.secrets.kv.v2.read_secret_version(
            path=path,
            mount_point='secret'
        )
        data = response['data']['data']
        return data[key] if key else data

    def get_db_credentials(self, role: str = 'readonly') -> dict:
        """获取动态数据库凭证"""
        response = self.client.read(f'database/creds/{role}')
        return {
            'username': response['data']['username'],
            'password': response['data']['password'],
            'lease_id': response['lease_id'],
            'lease_duration': response['lease_duration']
        }

    def _start_renewal(self):
        """后台自动续租 Token"""
        def renew():
            while True:
                time.sleep(self.lease_duration * 0.7)  # 在 70% 时续租
                try:
                    self.client.auth.token.renew_self()
                except Exception as e:
                    print(f"Token renewal failed: {e}")
                    self._login()

        thread = threading.Thread(target=renew, daemon=True)
        thread.start()

# 使用示例
secrets = SecretsManager()
db_password = secrets.get_secret('myapp/config', 'db_password')
db_creds = secrets.get_db_credentials('readonly')
print(f"Dynamic DB User: {db_creds['username']}")

十五、生产环境 Checklist

在将 OpenBao 部署到生产环境之前，请逐一确认以下事项：

基础安全

TLS 已启用 — Listener 配置了有效的 TLS 证书
Swap 已禁用或加密 — 防止密钥数据泄露到磁盘
Root Token 已撤销 — 初始化完成后立即撤销
Unseal Key 安全分发 — 多人持有，物理隔离存储
Auto Unseal 已配置（如使用）— KMS 密钥受保护不可删除

存储与高可用

Raft 集群 3+ 节点 — 奇数节点，容忍 N/2 节点故障
持久化存储可靠 — 使用 SSD，IOPS 足够
自动备份已配置 — 每日 Raft Snapshot，上传到安全存储
备份恢复已测试 — 定期演练恢复流程

审计与监控

审计日志已启用 — 至少一个审计设备
审计日志转发 — 发送到集中式日志系统
Prometheus 监控 — 采集关键指标
告警规则已配置 — Sealed 状态、请求延迟、Raft 通信

访问控制

最小权限策略 — 每个应用只获得必要的权限
AppRole / K8s Auth — 应用使用自动化认证
Secret ID 限制 — 设置 secret_id_num_uses=1 和 secret_id_ttl
Token TTL 合理 — 默认 1h，最大不超过 24h

密钥管理

KV v2 引擎 — 启用版本控制
动态密钥 — 数据库等使用动态凭证，而非静态密码
密钥轮换计划 — 定期执行 bao operator rotate
Lease TTL 合理 — 动态凭证 ≤ 1h

十六、本章小结

本文从零开始，全面深入地解析了 OpenBao 的各个方面：

架构理解 — 掌握了 Barrier 加密屏障、多层密钥保护、请求处理流程等核心设计。
安装上手 — 从 Dev 模式体验到各平台安装方式，快速建立第一个实操经验。
Secret Engines — 深入学习了 KV v2（静态密钥）、Database（动态凭证）、PKI（证书管理）、Transit（加密即服务）等核心引擎。
认证授权 — 掌握了 AppRole、Kubernetes Auth、Token 体系和 ACL Policy 的设计与实践。
Seal/Unseal — 理解了 Shamir 分片与 Auto Unseal 的工作原理及迁移方案。
生产部署 — 完成了 TLS、Raft HA 集群、systemd 服务、审计日志的完整配置。
Kubernetes 集成 — 掌握了 Helm 部署、Agent Injector、CSI Provider 的使用方式。
应用集成 — 通过 Go 和 Python 示例，展示了应用如何安全地获取和续租密钥。

OpenBao 作为 HashiCorp Vault 的开源替代品，在保持 API 兼容性的同时，完全由社区驱动，是云原生时代密钥管理的理想选择。

参考文档

本文内容基于 OpenBao 官方文档校验，以下为核心参考链接：

OpenBao GitHub Repository — 源代码与 Issue
What is OpenBao? — 项目介绍
Installing OpenBao — 安装指南
Architecture — 内部架构
Seal/Unseal — 密封/解封机制
Configuration — 配置参考
Secret Engines — 密钥引擎
Auth Methods — 认证方式
Policies — ACL 策略
High Availability — 高可用模式
Agent and Proxy — Agent 与 Proxy
Kubernetes Platform — Kubernetes 集成

Kubernetes 全景解析 (0)：架构设计与核心概念

2026年4月9日 · 阅读需 20 分钟

Rainy

雨落无声，代码成诗 —— 致力于技术与艺术的极致平衡

"如果你觉得 Kubernetes 太复杂，那是因为它解决的问题本身就很复杂。"

在云原生（Cloud Native）的世界里，Kubernetes（简称 K8s）已经从"可选技能"变成了"基础设施常识"。无论你是后端工程师、DevOps 工程师，还是架构师，理解 K8s 的设计思想和运行机制，都是构建现代分布式系统的必修课。

然而，K8s 的学习曲线之陡峭也是出了名的。官方文档动辄数千页，概念繁多且相互关联，很容易让人陷入"见树木不见森林"的困境。

本系列文章将从架构设计出发，逐层深入到核心概念、工作负载管理、网络模型、存储体系、调度策略与安全机制，帮助你构建一套完整、系统的 K8s 认知框架。本文作为系列的第零章，将聚焦于最根本的问题：Kubernetes 是什么？它是如何设计的？它由哪些核心部分组成？

一、为什么需要 Kubernetes

1.1 容器化演进的必然之路

要理解 K8s 存在的意义，我们需要先回顾应用部署方式的演进历程：

阶段	部署方式	隔离性	资源利用率	启动速度	运维复杂度
物理机时代	应用直接部署在物理服务器上	无	低	-	高
虚拟机时代	Hypervisor 划分多个 VM	高	中	分钟级	中
容器时代	Docker 等容器引擎	中	高	秒级	中
编排时代	Kubernetes 等编排系统	中	高	秒级	低（自动化）

物理机时代，一个应用独占一台服务器，资源浪费严重。为了提高利用率，我们开始在同一个物理机上部署多个应用，但随之而来的是依赖冲突、端口争抢、一个应用崩溃拖垮整台机器等问题。

虚拟机时代，Hypervisor（如 VMware、KVM）在物理机上虚拟出多个独立的操作系统实例，实现了良好的隔离。但虚拟机本身就很重——一个 VM 动辄几个 GB，启动需要数分钟，而且携带了完整的 Guest OS，大量资源被浪费在运行重复的系统服务上。

容器时代，Docker 横空出世。容器共享宿主机的内核，不需要 Guest OS，一个镜像通常只有几十 MB，启动只需毫秒级。容器通过 Namespace 实现视图隔离，通过 Cgroups 实现资源限制，在轻量和隔离之间找到了一个绝佳的平衡点。

但容器解决的是**"如何打包和运行应用"的问题，却没有解决"如何管理成百上千个容器"**的问题。当你的应用从 3 个容器扩展到 3000 个，跨越几十台机器时，以下问题接踵而至：

哪个容器应该运行在哪台机器上？
容器挂了谁来重启？机器挂了谁来迁移？
如何实现滚动更新而不中断服务？
如何让前端服务发现后端服务的地址？
如何让外部流量均匀地分发到多个实例？

这就是 Kubernetes 登场的时刻。

1.2 K8s 解决的核心问题

Kubernetes 作为一个容器编排平台（Container Orchestration Platform），本质上解决的是一个大规模自动化管理的问题。它将运维人员从手工操作中解放出来，通过声明式配置和自动化控制循环，实现了：

自动部署与回滚：声明期望状态，K8s 负责将实际状态趋近期望状态
服务发现与负载均衡：内置 DNS 和 Service 机制，无需外部注册中心
自动扩缩容：根据 CPU/内存/自定义指标自动调整实例数量
自我修复：容器崩溃自动重启，节点故障自动迁移
滚动更新与蓝绿部署：零停机更新应用

1.3 K8s 的设计哲学

理解 K8s 的设计哲学，比记住一百个命令更有价值。K8s 的三个核心设计理念贯穿了它的每一个组件：

声明式（Declarative）而非命令式（Imperative）

命令式 vs 声明式

命令式：你告诉系统"做什么"——docker run nginx、kubectl scale deployment nginx --replicas=3
声明式：你告诉系统"你要什么"——提交一个 YAML 文件描述"我需要 3 个 Nginx 实例"，K8s 会持续工作直到实际状态与期望状态一致

声明式的好处是：可重复、可审计、可版本化。同一个 YAML 文件，无论执行多少次，结果都是一致的。

不可变基础设施（Immutable Infrastructure）

K8s 中的容器镜像一旦构建就不应该被修改。需要更新时，你应该构建新镜像、创建新版本，而不是 SSH 进容器里改配置。这与传统"登录服务器打补丁"的运维方式截然不同。

最终一致性（Eventual Consistency）

K8s 不保证你的请求立即生效，但保证系统最终会收敛到期望状态。这种设计牺牲了即时性，换取了极高的可靠性和容错能力。即使你同时提交了多个冲突的变更，系统也能通过控制循环最终达到一个一致的状态。

二、K8s 整体架构

Kubernetes 采用经典的主从架构（Master-Worker Architecture），分为**控制面（Control Plane）和数据面（Data Plane）**两个层级。理解这两个层面的职责划分，是理解 K8s 一切行为的基础。

2.1 架构全景图

2.2 控制面组件详解

控制面是 K8s 集群的"大脑"，负责全局决策和集群状态的维护。在生产环境中，为了保证高可用，控制面组件通常部署在多个独立的 Master 节点上。

kube-apiserver：集群的统一入口

kube-apiserver 是整个 K8s 系统的唯一入口。所有组件——无论是内部的 Scheduler、Controller，还是外部的 kubectl、CI/CD Pipeline——都通过 API Server 进行通信。

为什么所有通信都要经过 API Server？

这种设计被称为 "Hub-and-Spoke" 模式。它的好处是：

统一鉴权：所有请求都在一个地方进行认证（Authentication）、授权（Authorization）和准入控制（Admission Control）
解耦：各组件不需要知道彼此的存在，只需要与 API Server 交互
审计：所有操作都有统一的日志记录

API Server 本身是无状态的，它可以水平扩展。所有的状态数据都存储在 etcd 中。

etcd：集群的"真相之源"

etcd 是一个分布式的、一致的键值存储系统，基于 Raft 共识算法实现。它是 K8s 集群的唯一数据源（Single Source of Truth）——集群中所有的一切：节点信息、Pod 状态、配置数据、Secret……全部存储在 etcd 中。

etcd 是 K8s 的命脉

etcd 的性能直接决定了整个集群的响应速度
etcd 的数据丢失意味着集群状态的丢失（虽然 Pod 可以重建，但某些运行时状态无法恢复）
生产环境建议部署 3 或 5 个 etcd 节点（奇数个，满足 Raft 多数派要求）
必须定期备份 etcd 数据

kube-scheduler：调度决策者

当你创建一个 Pod 时，API Server 只是将这个 Pod 的信息记录到了 etcd 中——此时 Pod 还处于 Pending 状态，因为它还没有被分配到任何节点上。Scheduler 的职责就是为每个未调度的 Pod 选择一个最合适的节点。

调度过程分为三个阶段：

过滤（Filtering）：排除不满足条件的节点（资源不足、端口冲突、污点容忍不匹配等）
打分（Scoring）：对剩余节点进行优先级打分（亲和性、镜像本地性、负载均衡等），选择得分最高的节点
绑定（Binding）：将调度决策应用到集群，将 Pod 与选定节点进行绑定

调度框架（Scheduling Framework）

从 v1.19 起，Kubernetes 调度器采用插件化架构（Scheduling Framework），上述三个阶段对应调度框架中的核心扩展点。整个调度过程分为调度周期（Scheduling Cycle）和绑定周期（Binding Cycle），调度周期串行执行，绑定周期可并发执行。

参考文档：Scheduling Framework

kube-controller-manager：状态守护者

Controller Manager 运行着多个控制器（Controller），每个控制器都是一个独立的控制循环（Reconciliation Loop），负责监控集群的某一部分状态，并持续将其推向期望状态。

常见的内置控制器包括：

控制器	职责
Deployment Controller	确保 Deployment 管理的 Pod 副本数符合期望
ReplicaSet Controller	确保 ReplicaSet 管理的 Pod 副本数符合期望
Node Controller	监控节点健康状态，节点失联时触发 Pod 驱逐
Service Account Controller	为命名空间创建默认 ServiceAccount
EndpointSlice Controller	维护 Service 与 Pod 的映射关系（推荐使用 EndpointSlice 替代已废弃的 Endpoints）

控制器的本质：控制循环

每个控制器的工作模式都是相同的：

while true:
    实际状态 = 从 API Server 获取当前状态
    期望状态 = 从配置中获取期望状态
    if 实际状态 != 期望状态:
        执行调谐操作（创建/删除/更新）
    sleep(一段时间)

这就是 K8s 所谓的**"调谐（Reconciliation）"**机制。

cloud-controller-manager：云平台桥梁

如果你在 AWS、GCP、Azure 等云平台上运行 K8s，CCM 负责与云厂商的 API 交互，管理云平台特有的资源：

Node Controller：调用云 API 查询节点地址和状态
Route Controller：配置云平台的路由规则
Service Controller：创建云平台的负载均衡器（如 AWS ELB）

CCM 的引入使得 K8s 的核心代码不需要耦合任何特定云厂商的 SDK，实现了云平台无关性。

2.3 数据面组件详解

数据面（也叫 Worker Node）是实际运行应用工作负载的地方。每个 Worker 节点上运行着三个核心组件：

kubelet：节点上的"车间主任"

kubelet 是运行在每个 Worker 节点上的代理，它的职责是：

接收指令：从 API Server 获取分配到本节点的 Pod 规格（Spec）
管理容器：通过 CRI（Container Runtime Interface）调用容器运行时，创建和管理 Pod 中的容器
健康检查：定期执行 Liveness Probe、Readiness Probe 和 Startup Probe
状态上报：将节点和 Pod 的状态信息上报给 API Server

你可以把 kubelet 理解为一个"车间主任"——它不制定生产计划（那是 Scheduler 的事），但负责确保分配到自己车间的生产任务被正确执行。

kube-proxy：网络规则的维护者

kube-proxy 运行在每个节点上，负责维护节点的网络规则，实现 Service 的负载均衡和网络代理。它通过操作 iptables 或 IPVS 规则，将访问 Service 的流量转发到后端的 Pod。

简单来说，当你访问一个 Service 的 ClusterIP 时，kube-proxy 维护的规则会将流量自动转发到该 Service 关联的某个 Pod 上。

kube-proxy 是可选组件（v1.34+）

根据 Kubernetes 官方文档，kube-proxy 是一个可选组件。如果你使用的网络插件（CNI）自身实现了 Service 的数据包转发功能，并提供与 kube-proxy 等效的行为，那么你不需要在集群节点上运行 kube-proxy。

例如，Cilium 等现代 CNI 插件可以直接替代 kube-proxy 的功能，通过 eBPF 实现更高效的 Service 负载均衡和网络代理。

参考文档：Kubernetes Architecture - kube-proxy (optional)

Container Runtime：容器的实际执行者

kubelet 本身并不直接运行容器，而是通过 CRI（Container Runtime Interface） 标准接口调用容器运行时。常见的 CRI 兼容运行时包括：

containerd：目前最主流的选择，Docker 的核心运行时组件独立出来的版本
CRI-O：专为 Kubernetes 设计的轻量级运行时，由 Red Hat 主导
Kata Containers：提供虚拟机级别的隔离，适用于安全要求极高的场景

Docker 与 K8s 的"分手"

在 K8s 1.20 之前的版本中，kubelet 通过一个名为 dockershim 的内置组件直接与 Docker 通信。但从 K8s 1.24 开始，dockershim 被正式移除。这并不意味着你不能在 K8s 中运行 Docker 镜像——Docker 镜像遵循 OCI 标准，containerd 和 CRI-O 都能运行它们。移除的只是对 Docker daemon 的直接依赖。

三、核心概念模型

Kubernetes 中的一切都被抽象为 API 对象（API Object）。理解这些对象及其关系，是使用 K8s 的基础。

3.1 API 对象与声明式配置

在 K8s 中，你不需要告诉系统"如何做"，而是描述"你要什么"。你通过提交 YAML（或 JSON）文件来定义 API 对象，API Server 会将你的声明持久化到 etcd，然后各个控制器会持续工作，确保实际状态趋近于你声明的期望状态。

3.2 YAML 配置结构解析

每个 K8s API 对象的 YAML 配置都遵循以下结构：

apiVersion: apps/v1          # API 版本，标识对象属于哪个 API 组
kind: Deployment             # 对象类型，K8s 内置了几十种对象类型
metadata:                    # 对象的元数据（名称、标签、注解等）
  name: nginx-deployment
  namespace: default
  labels:
    app: nginx
    tier: frontend
spec:                        # 对象的规格（期望状态）
  replicas: 3                # 期望运行 3 个 Pod 副本
  selector:                  # 选择器，用于关联管理的 Pod
    matchLabels:
      app: nginx
  template:                  # Pod 模板，定义如何创建 Pod
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 512Mi

YAML 配置的四个必填字段

apiVersion：指定 API 版本。v1 是核心 API 组，apps/v1、networking.k8s.io/v1 等是扩展 API 组
kind：对象类型，如 Pod、Deployment、Service、ConfigMap 等
metadata：对象的"身份证"，至少包含 name，通常还包含 labels 和 annotations
spec：对象的"期望状态"，不同类型的对象有不同的 spec 结构

3.3 API 对象层级关系

K8s 的 API 对象之间存在着清晰的层级关系。上层对象管理下层对象，形成了一个从粗粒度到细粒度的管理链。

Pod：K8s 的最小调度单元

初学者常有一个疑问：为什么 K8s 的最小单位是 Pod 而不是 Container？

Pod 是一个逻辑概念，它可以包含一个或多个紧密耦合的容器。这些容器共享：

网络命名空间：同一个 Pod 中的容器可以通过 localhost 互相访问
存储卷：可以挂载共享的 Volume
运行约束：总是被调度到同一个节点上

一个典型的多容器 Pod 场景是"Sidecar 模式"：主容器运行应用逻辑，Sidecar 容器负责日志收集、监控数据导出或代理转发。

四、一次请求的完整旅程

理论讲了不少，现在让我们通过一个具体的场景来串联所有知识：当你执行 kubectl apply -f nginx-deployment.yaml 时，K8s 内部到底发生了什么？

4.1 完整时序图

4.2 控制循环（Reconciliation Loop）详解

时序图展示了一次性的创建流程，但 K8s 的真正威力在于其持续运行的控制循环。让我们深入理解这个机制：

第一步：感知变化（Watch 机制）

K8s 的各个组件并不是定期轮询 API Server，而是通过基于 HTTP 长连接的 Watch 机制 来感知变化。当你创建、修改或删除一个对象时，API Server 会通过 Watch 通道将事件推送给所有订阅者。事件类型包括：

ADDED：新对象被创建
MODIFIED：对象被更新
DELETED：对象被删除

这种基于事件驱动的设计，比轮询更高效，延迟更低。

第二步：计算差异（Diff）

控制器收到事件后，会将实际状态与期望状态进行对比。例如，Deployment Controller 发现期望的副本数是 3，但当前只有 2 个 Pod 在运行。

第三步：执行调谐（Reconcile）

控制器计算出需要执行的操作后，会通过 API Server 发起调谐请求。在上面的例子中，Deployment Controller 会创建一个新的 ReplicaSet，ReplicaSet Controller 会创建一个新的 Pod。

第四步：重复

整个过程是一个无限循环。即使某个操作失败了，下一轮循环也会再次尝试。这就是 K8s 实现自愈能力的根本原因。

水平扩展：自定义控制器

K8s 的控制器模式不仅限于内置资源。通过 CRD（Custom Resource Definition） 和 Operator 模式，你可以定义自己的 API 对象和对应的控制器。例如，Prometheus Operator 可以管理 Prometheus 实例的生命周期，Cert-Manager Operator 可以自动化 TLS 证书的申请和续期。这就是 K8s 被称为"平台的平台"的原因。

五、本章小结与下一篇预告

本文作为 Kubernetes 全景解析系列的第零章，我们从宏观视角梳理了 K8s 的全貌：

维度	核心要点
设计哲学	声明式配置、不可变基础设施、最终一致性
架构分层	控制面（决策）+ 数据面（执行）
控制面组件	API Server（入口）、etcd（存储）、Scheduler（调度）、Controller Manager（控制循环）
数据面组件	kubelet（节点代理）、kube-proxy（网络代理）、CRI（容器运行时）
核心抽象	一切皆 API 对象，通过 YAML 声明期望状态
运行机制	Watch 事件驱动 + 控制循环持续调谐

掌握这些基础知识后，你将不再对 K8s 感到迷茫——它的每一个行为都可以追溯到上述架构和机制中。

下一篇，我们将深入 K8s 的工作负载管理： 从 Pod 的生命周期到 Deployment、StatefulSet、DaemonSet 等工作负载控制器的使用场景与最佳实践。理解了工作负载，你就能真正开始在 K8s 上部署和运行应用了。

系列导航

章节主题状态
0 架构设计与核心概念 ✅ 已发布
1 工作负载与 Pod 生命周期深度解析 ✅ 已发布
2 网络模型与服务发现全链路解析 ✅ 已发布
3 存储体系与配置管理深度剖析 ✅ 已发布
4 调度器、资源管理与弹性伸缩 ✅ 已发布
5 安全体系与可观测性全景 ✅ 已发布
6 生产级微服务架构实战 ✅ 已发布
7 有状态应用与 Operator 模式实战 ✅ 已发布

章节	主题	状态
0	架构设计与核心概念	✅ 已发布
1	工作负载与 Pod 生命周期深度解析	✅ 已发布
2	网络模型与服务发现全链路解析	✅ 已发布
3	存储体系与配置管理深度剖析	✅ 已发布
4	调度器、资源管理与弹性伸缩	✅ 已发布
5	安全体系与可观测性全景	✅ 已发布
6	生产级微服务架构实战	✅ 已发布
7	有状态应用与 Operator 模式实战	✅ 已发布

参考文档

本文内容基于 Kubernetes 官方文档校验，以下为核心参考链接：

Kubernetes Cluster Architecture — 集群架构概览
Kubernetes Components — 核心组件说明
kube-proxy (optional) — kube-proxy 可选组件说明
Scheduling Framework — 调度框架
Container Runtimes — 容器运行时
Kubernetes v1.34 Release Notes — v1.34 版本发布说明

一、OpenBao 是什么？​

1.1 项目背景与定位​

1.2 核心能力概览​

1.3 核心术语速查​

二、架构深度解析​

2.1 整体架构​

2.2 加密屏障（Barrier）工作原理​

2.3 请求处理流程​

三、安装与快速上手​

3.1 安装方式​

macOS（Homebrew）​

Linux（包管理器）​

Docker 容器​

从源码编译​

3.2 Dev 模式快速体验​

3.3 第一个 Secret：KV 引擎实战​

3.4 HTTP API 直接调用​

四、Secret Engines 深度解析​

4.1 引擎全景​

4.2 动态密钥：Database 引擎实战​

4.3 PKI 引擎：内部 TLS 证书管理​

4.4 Transit 引擎：加密即服务（EaaS）​

五、认证与授权​

5.1 Auth Methods 概览​

5.2 AppRole 认证实战（推荐用于应用）​

5.3 Kubernetes 认证​

5.4 Token 类型与层级​

六、ACL 策略（Policies）​

6.1 策略语法​

6.2 权限说明​

6.3 策略管理​

6.4 策略模板（参数化策略）​

七、Seal / Unseal 机制详解​

7.1 Shamir 分片（默认）​

7.2 Auto Unseal（推荐用于生产）​

7.3 Seal 迁移​

八、生产级部署​

8.1 生产配置文件​

8.2 systemd 服务配置​

8.3 初始化与首次启动​

九、高可用（HA）集群​

9.1 Integrated Storage（Raft）HA 架构​

9.2 集群节点配置​

9.3 加入集群​

9.4 HA 运维操作​

十、审计日志​

10.1 启用审计​

10.2 审计日志格式​

十一、Kubernetes 集成​

11.1 Helm 部署 OpenBao​

11.2 Agent Injector：自动为 Pod 注入密钥​

11.3 CSI Provider（另一种注入方式）​

十二、OpenBao Agent / Proxy​

12.1 Agent 模式​

12.2 Proxy 模式​

十三、运维与监控​

13.1 关键监控指标​

13.2 Prometheus 集成​

13.3 备份与恢复策略​

13.4 密钥轮换​

十四、应用集成模式​

14.1 应用读取密钥的四种方式​

14.2 Go 应用集成示例​

14.3 Python 应用集成示例​

十五、生产环境 Checklist​

基础安全​

存储与高可用​

审计与监控​

访问控制​

密钥管理​

十六、本章小结​

参考文档​

一、为什么需要 Kubernetes​

1.1 容器化演进的必然之路​

1.2 K8s 解决的核心问题​

1.3 K8s 的设计哲学​

二、K8s 整体架构​

2.1 架构全景图​

2.2 控制面组件详解​

kube-apiserver：集群的统一入口​

一、OpenBao 是什么？

1.1 项目背景与定位

1.2 核心能力概览

1.3 核心术语速查

二、架构深度解析

2.1 整体架构

2.2 加密屏障（Barrier）工作原理

2.3 请求处理流程

三、安装与快速上手

3.1 安装方式

macOS（Homebrew）

Linux（包管理器）

Docker 容器

从源码编译

3.2 Dev 模式快速体验

3.3 第一个 Secret：KV 引擎实战

3.4 HTTP API 直接调用

四、Secret Engines 深度解析

4.1 引擎全景

4.2 动态密钥：Database 引擎实战

4.3 PKI 引擎：内部 TLS 证书管理

4.4 Transit 引擎：加密即服务（EaaS）

五、认证与授权

5.1 Auth Methods 概览

5.2 AppRole 认证实战（推荐用于应用）

5.3 Kubernetes 认证

5.4 Token 类型与层级

六、ACL 策略（Policies）

6.1 策略语法

6.2 权限说明

6.3 策略管理

6.4 策略模板（参数化策略）

七、Seal / Unseal 机制详解

7.1 Shamir 分片（默认）

7.2 Auto Unseal（推荐用于生产）

7.3 Seal 迁移

八、生产级部署

8.1 生产配置文件

8.2 systemd 服务配置

8.3 初始化与首次启动

九、高可用（HA）集群

9.1 Integrated Storage（Raft）HA 架构

9.2 集群节点配置

9.3 加入集群

9.4 HA 运维操作

十、审计日志

10.1 启用审计

10.2 审计日志格式

十一、Kubernetes 集成

11.1 Helm 部署 OpenBao

11.2 Agent Injector：自动为 Pod 注入密钥

11.3 CSI Provider（另一种注入方式）

十二、OpenBao Agent / Proxy

12.1 Agent 模式

12.2 Proxy 模式

十三、运维与监控

13.1 关键监控指标

13.2 Prometheus 集成

13.3 备份与恢复策略

13.4 密钥轮换

十四、应用集成模式

14.1 应用读取密钥的四种方式

14.2 Go 应用集成示例

14.3 Python 应用集成示例

十五、生产环境 Checklist

基础安全

存储与高可用

审计与监控

访问控制

密钥管理

十六、本章小结

参考文档

一、为什么需要 Kubernetes

1.1 容器化演进的必然之路

1.2 K8s 解决的核心问题

1.3 K8s 的设计哲学

二、K8s 整体架构

2.1 架构全景图

2.2 控制面组件详解

kube-apiserver：集群的统一入口