vault 管理 ci/cd 密钥的核心是“不落地、不硬编码、有权限、能轮换”，需启用 kv v2 引擎、配置最小权限策略、通过 approle 或 github oidc 动态获取短期令牌，并在流水线中安全注入密钥。
直接用 Vault 管理 CI/CD 流水线里的密钥，核心是“不落地、不硬编码、有权限、能轮换”。关键不在存，而在怎么安全地取、限时地用、精准地控。
Vault 中为 CI/CD 单独启用 KV v2 引擎
KV v2 是推荐选择，它支持版本控制、软删除和元数据审计，比 v1 更适合自动化场景。CI/CD 流水线通常只需要读取能力，所以启用时明确路径范围即可：
- 执行 vault secrets enable -path=ci-cd kv-v2 启用引擎
- 写入密钥示例：vault kv put ci-cd/data/deploy-token token=abc123 env=prod
- v2 路径下实际访问需带 data/ 前缀，如读取路径是 ci-cd/data/deploy-token
用最小权限策略限制流水线只读指定路径
绝不能给 CI/CD 流水线用 root token 或宽泛策略。应创建专用策略，仅允许读取 ci-cd/data/* 下的密钥：
- 策略文件 ci-cd-policy.hcl 内容： path "ci-cd/data/*" { capabilities = ["read"] }
- 加载策略：vault policy write ci-cd-policy ci-cd-policy.hcl
- 后续所有流水线使用的 token 都必须绑定此策略，杜绝越权读取其他路径
通过 AppRole 或 GitHub OIDC 动态获取短期令牌
静态 token 有泄露风险，应让流水线每次运行都动态领取短期凭证：
- AppRole 方式：在 Vault 中创建 role，配置 secret_id_ttl（如 10m）和 token_ttl（如 5m），流水线先取 secret_id，再换 token
- GitHub OIDC（推荐）：利用 GitHub Actions 的 OpenID Connect 身份，Vault 直接验证 JWT，无需预置 secret_id，更安全简洁
- 无论哪种方式，生成的 token 默认自动过期，且无法续期，天然防长期滥用
在流水线中安全调用 Vault 获取密钥
避免把 token 写进脚本或日志。推荐两种落地方式：
- 环境变量注入：在 job 开始前，用 vault read -format=json ci-cd/data/db-creds 解析出字段，再 export 到环境变量，供后续命令使用
- 配合 openclaw 客户端：用容器化工具 openclaw-hashicorp-vault，在应用启动前自动拉取并注入密钥到文件或 env，自身不留凭证痕迹
- 注意：所有 vault 命令输出需过滤敏感字段，禁止直接 echo 或记录完整响应体
