2. AWS Secrets Manager：核心概念与架构
好，咱们正式进入 AWS Secrets Manager。我在项目里用了它好几年，说实话，它是我见过对开发者最友好的 Secrets 服务之一。但如果你只把它当成一个“存密码的保险箱”，那就亏大了。
我会带你拆开它的几个核心概念，再画一张架构图，把各个部件怎么配合说清楚。
2.1 核心概念
先过一遍必须搞懂的基本单位。这些名词在 AWS 文档里频繁出现，但很多新手一开始容易搞混。
说到底，Secrets Manager 的核心就是：托管 + 轮换 + 细粒度控制。
2.1.1 Secret
Secret 是基本存储单元。它可以是一个数据库密码、、OAuth ，甚至整段 JSON 配置。每个 Secret 有一个唯一的 ARN（Amazon Resource Name），像身份证一样。
我个人习惯给 Secret 命名时带上环境前缀，比如 prod/rds/mysql-user，这样在控制台里一眼能看出归属。
2.1.2 Version（版本）
每个 Secret 内部管理着多个版本。你每次更新 Secret，会自动生成一个新版本，同时保留旧版本。这有什么用？
- 回滚：如果新密码导致服务异常，可以快速切回上一个版本。
- 轮换过渡：旋转期间新旧密码并存，保证应用不中断。
我之前遇到过生产环境轮换后应用报错，原因就是应用还没更新缓存，但旧版本已经被删了。后来我强制保留了两到三个版本，再也没有因为这个出过问题。
2.1.3 Rotation（轮换）
这是 Secrets Manager 的招牌功能。你可以配置自动轮换周期（比如每30天），它会调用一个 Lambda 函数来生成新密码并更新目标服务（RDS、DocumentDB 等）。
注意：轮换不是直接改原 Secret 的值，而是先创建新版本，再逐步切换。默认使用“单用户轮换”，新密码生成后旧密码被废弃；如果你需要同时保留新旧密码，要用“多用户轮换”。
我建议初学者先从手动轮换开始，熟悉流程后再开自动。直接开自动轮换，一旦 Lambda 权限配错，轮换会失败，你的密码就卡在中间状态了。
2.1.4 Resource-based Policy（基于资源的策略）
和 S3 的 Policy 类似，你可以直接给某个 Secret 附加一个 JSON 策略，控制哪些 IAM 用户、角色、账户能访问它。它和 IAM identity-based policy 共同生效，取交集。
一个小技巧： 跨账户共享 Secret 时，必须用 resource-based policy。IAM 策略只能管本账户。我之前帮一个团队做多账户统一密钥管理，就是用这个方式把一个主账户里的 Secret 授权给多个子账户的应用。
| 概念 | 说明 | 常见误区 |
|---|---|---|
| Secret | 名称+ARN+加密内容 | 以为 Secret 只能存纯文本，其实支持二进制和 JSON |
| Version | 每个 Secret 多个版本（最多100个） | 删除旧版本时忘记保留至少一个可用版本 |
| Rotation | 自动定期更替密钥 | Rotation 必须依赖 Lambda，不是内置功能 |
| Policy | 资源级访问控制 | 只给 IAM 策略，不给 resource-based 策略导致跨账户失败 |
2.2 架构总览
光看概念还不够，咱们看看 Secrets Manager 在 AWS 内部是怎么工作的。下面这张图是我自己总结的，能帮你快速理清各个角色的定位。
简单解释一下这张图里的流程：
- 用户或应用发出请求（GetSecretValue / PutSecretValue），首先经过 IAM 权限验证身份。
- 通过后，请求到达 Secrets Manager 控制平面，这里负责 API 路由和版本管理。
- 控制平面调用 KMS 对 Secret 内容进行加密/解密。
- 加密后的密文存储在 数据平面（一个高可用分布式存储后端）。
- 如果需要轮换，Lambda 轮换函数会被触发，它从数据平面读取当前 Secret，生成新密码，并更新 目标服务（比如 RDS）。
- 所有操作日志会送到 CloudWatch Logs，方便审计和排障。
2.3 加密原理
Secrets Manager 默认使用 AWS 托管密钥（aws/secretsmanager），你也可以指定自定义 KMS 密钥。为什么我推荐用自定义密钥？
- 更细粒度的控制：可以给不同团队分配不同的 CMK，实现加密域隔离。
- 审计更清晰：每个 CMK 的访问记录会出现在 CloudTrail 中，你一眼能看出哪个 Secret 被谁解密了。
- 轮换 CMK 本身：如果密钥泄露，你可以直接禁用或轮换 CMK，然后 Secrets Manager 会自动重新加密所有 Secret。
警告： 如果你使用了自定义 KMS 密钥，记得给 Secrets Manager 服务添加 kms:Decrypt 和 kms:GenerateDataKey 权限。我曾经因为忘了配 KMS 权限，导致生产环境获取 Secret 时一直返回 AccessDenied，排查了半小时才发现是密钥策略的问题。
2.4 几个常见误区
最后分享几个我见过的坑，希望能帮你省点时间：
- 误区一：以为 Secrets Manager 只适合 RDS 密码。 其实它支持任何场景——、第三方令牌、配置文件中的敏感字段。
- 误区二：频繁调用 GetSecretValue。 一次调用费用不高，但高并发场景下延迟和费用都会上来。我建议在应用启动时把 Secret 缓存到内存（比如每1小时刷新一次），而不是每次都去 API 请求。
- 误区三：批量删除 Secret 时不检查是否还有版本。 如果你删除了一个还有版本号引用的 Secret，可能会造成其他服务报错。稳妥做法是先删除所有版本，再删除 Secret 本身。
嗯，核心概念和架构就这些。这些东西看一遍可能记不住，但你先在心里留个框架，后面讲到实操时，我会再结合这些概念一步步演示。