4. AWS Secrets Manager 简介:发展历程、核心架构、适用场景
如果你在云上管过几千个密钥,你一定懂那种痛苦——硬编码、轮转靠人肉、泄露了只能烧香。说实话,AWS 自己早期也没有太好的解法。直到 Secrets Manager 出来,我才觉得这块终于有人认真做了。
4.1 发展历程:从 Parameter Store 到独立服务
记得 2018 年 AWS 发布 Secrets Manager 时,我第一反应是“嗯,这不就是 Parameter Store 加了个自动轮转吗?”后来用上了才发现,差得远着呢。
- 2012 年:AWS 推出 IAM 角色和临时凭证,解决了 EC2 上密钥分发的部分痛点,但静态密钥(数据库密码、API )还是得靠文件或环境变量。
- 2016 年:AWS Systems Manager Parameter Store 上线,能存储加密参数。但轮转只靠 AWS Lambda 自己写,而且没有“版本管理”概念——说白了就是一个加密版 key-value 存储。
- 2018 年 re:Invent:AWS Secrets Manager 正式发布。最大的杀手锏是自动轮转:你可以绑定一个 Lambda 函数,定期换密码,应用那边几乎无感知。
- 2019-2023 年:陆续支持跨账户访问、多区域复制、与 RDS/Aurora 原生集成。现在基本是托管密钥管理的事实标准。
4.2 核心架构:你管密钥,AWS 管轮转
先看整体结构,我画了个简图帮你理解各个组件怎么配合的。
核心逻辑其实不复杂:用户通过控制台或 API 创建一个密钥(比如数据库密码),Secrets Manager 会用 AWS KMS 的客户主密钥(CMK)加密它。当应用请求这个密钥时,Secrets Manager 解密并返回明文(可以通过缓存减少调用)。真正的魔法藏在自动轮转里。
版本管理机制
Secrets Manager 用“分区键”来管理多个版本。每次轮转会产生一个新版本,老版本标记为“待删除”或“历史”,默认保留 7 天。应用可以拿到特定的 staging label(比如 AWSCURRENT、AWSPREVIOUS)。
AWSCURRENT 版本,轮转后新密码生效,旧连接瞬间断开。解决方案是让应用先切换到 AWSPREVIOUS,等连接 drain 完再触发轮转。说白了,轮转前要做好读取准备。
4.3 适用场景:什么时候该用,什么时候别用
说实话,Secrets Manager 不是万金油。它的定价是按密钥数和 API 调用量来的——每月每密钥 0.40 美元,外加每万次 API 调用 0.05 美元。对,比 Parameter Store 贵不少。但有些场景确实值得掏这个钱。
| 场景 | 推荐程度 | 理由 |
|---|---|---|
| RDS / Aurora 数据库密码 | ★★★★★ | 原生集成,有官方轮转模板,几分钟配好 |
| 第三方 API (OAuth、SaaS) | ★★★★ | 可以自己写 Lambda 轮转,但注意 API 限流 |
| 跨账户共享密钥 | ★★★★ | 资源策略 + KMS 跨账户授权,比 Parameter Store 灵活 |
| 高频率访问的静态配置(每分钟上千次) | ★★ | 使用 Client 端缓存,否则 API 费用爆炸 |
| 单纯存个 SSH 密钥不轮转 | ★ | Parameter Store 免费版更划算 |
另外,如果你的团队已经深度使用了 HashiCorp Vault,不建议强行换到 Secrets Manager。Vault 的动态密钥、租约机制、多后端集成比 AWS 成熟得多。但如果你整个基础设施都在 AWS 上,且没有专门的密钥运维团队,Secrets Manager 开箱即用的体验是非常香的。
一句话判断
需要自动轮转数据库密码或合规性审计要求(比如 SOC 2 要求密钥每 90 天更换一次)——选 Secrets Manager。只是存个不常变动的配置——Parameter Store 免费版就够用了。