主流 Secrets Manager 产品概览
选型的第一步，是搞清楚市场上都有哪些选手。我最早接触 Secrets Manager 时，面对一堆名字也懵过。AWS Secrets Manager、Azure Key Vault、GCP Secret Manager、HashiCorp Vault、Kubernetes Secrets……
说白了，它们分两大类：
- 云厂商原生服务：跟自家云平台深度绑定，开箱即用，省心。
- 开源/第三方方案：跨云、混合云场景更灵活，但运维成本你得上心。
下面我挨个聊聊，顺便讲讲我在项目中踩过的坑。
云厂商原生方案
AWS Secrets Manager
AWS 家的产品，我用的最多。它的核心卖点是 自动轮换，尤其跟 RDS、Redshift 这些服务集成时，简直不要太爽。我有个项目，用户要求数据库密码每 30 天必须改一次。如果用传统方式，运维得写脚本、配定时任务，累死人。
AWS Secrets Manager 怎么做？直接勾选自动轮换，指定一个 Lambda 函数就行。它替你生成新密码，同步更新数据库，旋转期间应用无感知。
我个人的习惯是：只要在 AWS 环境里，首选 Secrets Manager。计费按每个 Secret 每月 0.40 美元起步，加上 API 调用费。对于需要频繁轮换的场景，这笔钱花得值。
优点很明显：
- 与 IAM、KMS、CloudTrail 无缝集成
- 支持跨账户共享
- 内置轮换模板，支持多种数据库
但也有坑：
- 价格比其他云厂商贵一截
- 只支持轮换时的版本管理，不支持任意版本回退
注意：如果你是 AWS 重度用户，但预算敏感，可以看看 AWS Systems Manager Parameter Store 的 SecureString 参数。它便宜很多，但没有自动轮换。怎么选？看需求。
Azure Key Vault
Azure 对应的方案是 Key Vault。不止管密钥，也管证书和机密。
有一说一，Azure 在 访问控制 上做得挺细。它的 RBAC 模型支持对单个 Secret 的读取、列出、设置等操作分别授权。我记得之前做 Azure 项目，安全部门要求不同团队只能看到自己创建的密钥——Key Vault 的 RBAC 完美满足。
关键特性：
- 硬件安全模块（HSM）支持，FIPS 140-2 Level 2/3
- 支持软删除和清除保护，误删了能救回来
- 与 Azure AD、Azure Policy 集成
价格方面：标准层每 10,000 次操作收费约 0.03 美元，有免费层（每天 20,000 次操作）。
小提示：Azure Key Vault 的软删除默认不开启，需要手动启用。我一开始没注意，测试环境删了个 Secret 直接找不回来，只能重建。别学我。
GCP Secret Manager
GCP 的 Secret Manager 出道较晚，但 API 设计很现代。
它最吸引我的是 按版本管理。每个 Secret 可以有多个版本，版本号自动递增，还能给版本打别名。回滚时，直接把应用指向旧版本就行，不像 AWS 那样需要手动写轮换脚本。
| 特性 | GCP Secret Manager |
|---|---|
| 自动轮换 | 仅支持基于时间的调度轮换（需配合 Cloud Scheduler + Cloud Functions） |
| 密钥轮换 | 创建新版本，旧版本保留 |
| IAM 集成 | 支持细粒度 IAM 权限控制 |
| 审计日志 | Cloud Audit Logs |
| 价格 | 每个 Secret 每月 0.06 美元 + 每 10,000 次访问 0.03 美元 |
GCP 的计费模式比较清晰，就是按 Secret 数量和 API 调用次数。如果你在 GCP 上跑微服务，Secret Manager 的 API 延迟通常在 10ms 以内，性能不错。
开源与第三方方案
HashiCorp Vault
HashiCorp Vault 是开源阵营的王者。它不依赖任何云平台，支持多种 Secrets Engine，比如 AWS 动态凭证、数据库动态凭证、PKI 证书签发等等。
我曾在混合云场景用过 Vault。云上跑着 AWS，机房里有虚拟机。统一用 Vault 管理所有 和证书，效果很好。但它有个门槛——部署和运维复杂度不低。你要搭集群、配置存储后端（比如 Consul、Raft）、管理 Unseal 流程。团队里没个懂的人，容易翻车。
我的经验是：小项目用 Vault 有点大材小用，但一旦你玩转了动态凭证，就再也回不去了。比如让 Vault 给应用生成一个临时数据库账号，用完即废，这才是 Secrets 管理的理想形态。
缺点也摆在这儿：
- 运维人员需要学习 Vault 的配置和策略语法
- 高可用部署最少 3 节点，资源成本不低
- 需要定期备份存储后端的快照
Kubernetes Secrets
K8s 内置的 Secret 对象，你肯定用过。但它 不是真正的 Secrets Manager。
它做了什么？把数据 base64 编码存到 etcd。加密默认是关闭的，etcd 一旦被攻破，所有 Secrets 相当于明文。我见过太多人以为 base64 就是加密了……不是的，那只是编码。
千万注意：
- 生产环境务必开启 Etcd 加密（EncryptionAtRest）
- 不要直接写 YAML 硬编码 Secret 值
- 配合 External Secrets Operator 或 Vault Agent 注入器来管理 Secret
我之前有个项目，因为没开加密，安全扫描直接报高危漏洞。改起来倒是简单，但整改过程挺烦的。还是尽早规范好。
K8s Secrets 适合存放不敏感的配置 或者用于开发测试环境。生产环境，建议用它注入外部 Secrets Manager 的凭据，而不是直接存敏感信息。
其他开源方案：SOPS & Mozilla sops
如果只想加密配置文件，SOPS（Mozilla sops）是个轻量选择。它用 AWS KMS、GCP KMS、Azure Key Vault 或者 PGP 密钥加密 YAML/JSON 文件。适合 GitOps 场景，加密后的文件可以直接入库。
它的理念是“把加密密钥和配置文件分开”。比如你用 KMS 加密一个 secrets.yaml，提交到 Git。CI/CD 时解密并注入应用。简单、好理解，但没有运行时 API，不具备动态管理能力。
产品对比全景图
看完上面的介绍，可能有点乱。下面这张图帮你梳理一下几种方案的定位和关系。
表格：核心参数对比
最后，我把几个主流方案的决策关键点列在一张表里。你选型时，可以对着这张表问自己：我的场景更看重哪个点？
| 产品 | 部署模式 | 自动轮换 | 动态凭证 | 审计日志 | 运维复杂度 | 推荐场景 |
|---|---|---|---|---|---|---|
| AWS Secrets Manager | 云托管 | ✅ 内置（Lambda） | 仅数据库 | CloudTrail | 低 | AWS 重度用户，需要自动轮换 RDS 密码 |
| Azure Key Vault | 云托管 | ❌ 需手动/脚本 | ❌ | Azure Monitor | 低 | Azure 环境，需要 HSM 合规 |
| GCP Secret Manager | 云托管 | ⏳ 调度 + 函数 | ❌ | Cloud Audit Logs | 低 | GCP 微服务，重视版本管理 |
| HashiCorp Vault | 自托管 / 托管 | ✅ 支持 | ✅ 多种引擎 | 配置可对接 | 高 | 混合云/多云，需要动态凭证 |
| K8s Secrets | K8s 内置 | ❌ | ❌ | K8s Audit | 低 | 开发测试 / 配合外部注入器使用 |
| SOPS | 文件级加密 | ❌ | ❌ | Git 本身 | 低 | GitOps 场景，加密秘钥入 Git |
嗯，产品概览就聊到这儿。你会发现，没有完美的方案，只有适合你的方案。后面的章节我会逐一深入每个产品的配置和实战坑点，到时候再细聊。