1. Secrets Manager 是什么？从一次事故说起
聊 Secrets Manager 之前，我想先讲个我亲身经历的事。
几年前我负责一个微服务迁移项目。团队把数据库密码直接写在了配置中心，还觉得加密存储就万事大吉。结果一次配置中心权限被误改了，整个生产环境的数据库凭证几乎是裸奔。嗯，那天的告警电话、凌晨两点回滚、事后复盘时CTO铁青的脸……到现在我都记得。
从那以后我就牢牢记住了：敏感信息（密码、、）必须跟普通配置分开管理。而 Secrets Manager 就是专门干这个的——它不是一个花哨的功能，而是你云上资产的最后一道门锁。
1.1 核心概念速览
先给你一张全景图，我们一个个拆解。
说白了，Secrets Manager 就做三件事：存好、管好、看好你的敏感数据。上面的图里，中间是核心引擎，周围五个概念分别是它要处理的对象和机制。
1.2 核心概念逐个拆解
1.2.1 Secret（密钥）
这是最基本的单元。一个 Secret 就是一个「键值对」，比如 DB_PASSWORD=Abc123...。但注意，它不光能存密码，还能存 SSH 密钥、OAuth 、证书私钥。我个人习惯把所有非对称敏感信息都扔进去，绝不放配置中心。
- 名称：全局唯一标识，比如
prod/db/master - 值：加密存储，支持明文或 JSON 结构
- 标签：打上环境、团队等元数据，方便搜索
test/db/xxx、DB_PROD 混着来，后来审计时完全对不上号。
1.2.2 Secret Version
每个 Secret 可以有多个版本。为什么要版本？你想想看，轮换密码时新密码替换旧密码，但旧密码可能还被某些容器缓存着。版本化让你可以平滑过渡。
| 版本号 | 状态 | 说明 |
|---|---|---|
| 1 (DEPRECATED) | 已弃用 | 旧密码，被自动轮换标记为过期 |
| 2 (CURRENT) | 当前生效 | 应用默认读取的版本 |
| 3 (PENDING) | 待激活 | 用于灰度验证，不自动给全部应用 |
1.2.3 自动轮换
这是 Secrets Manager 最值钱的功能。你能设定一个周期（比如 30 天），系统自动生成新值、更新目标服务（比如数据库用户密码）、标记旧版本。我曾经的教训就是没有轮换，直到安全扫描报告暴露了半年未改的默认密码。从那以后，我坚持所有生产凭证必须开启自动轮换。
ALTER USER ...。这一步很多人会忘，轮换就成了「只改 Secrets Manager 里的值，实际数据库没变」的假动作。
1.2.4 访问策略（Resource-based Policy）
谁可以读？谁可以写？谁可以轮换？这些通过 IAM 策略 + 资源策略控制。你可以精细到「只允许 prod 环境的 ECS 实例读取 prod/db/* 下的 Secret，且只能读当前版本」。我用过一种经典组合：
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:us-east-1:123456:secret:prod/*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456"
}
}
}]
}嗯，这里要注意：永远不要给 secretsmanager:* 的通配符权限，除非你想上明天的安全事故日报。
1.2.5 审计日志
每一次读取、创建、更新、删除，都应该被记录。CloudTrail 或第三方审计工具能告诉你「谁在什么时候读了哪个 Secret」。合规要求（如 SOC2、PCI-DSS）一般都会要求有这条记录。
1.3 什么时候该用？什么时候别用？
我整理了一个快速决策清单，帮你判断：
| 场景 | 推荐使用 | 理由 |
|---|---|---|
| 数据库密码、、 | ✅ Secrets Manager | 需要轮换、审计、版本管理 |
| 应用配置（比如日志级别、功能开关） | ❌ 配置中心 / AppConfig | 这些不敏感，Secrets Manager 成本高、不适合高频读取 |
| SSL 证书私钥 | ✅ Secrets Manager | 配合 ACM 自动续期，它是个很好的中间存储 |
| 临时生成的密码（一次性使用） | ⚠️ 酌情 | 可以用但成本不合理，不如直接加密传给客户端 |
1.4 从一个接口理解核心流程
Secrets Manager 对外提供 REST 接口。我们来拆一个最常见的操作——获取 Secret 值。
- 客户端请求：
POST /secretsmanager/GetSecretValue，带上SecretId和可选的VersionId - 鉴权：验证请求者的 IAM 权限 + 资源策略
- 解密：系统从加密存储中拉取密文，用 KMS 主密钥解密
- 审计：写入 CloudTrail 事件：用户名、时间、SecretId
- 返回：明文 Secret 值，缓存时间由客户端控制（建议不超过 5 分钟）
你看，一次看似简单的 get 调用，背后要过鉴权、解密、审计三道坎。这就是为什么我总说「Secrets Manager 不只是存密码，它是一个安全基础设施」。
1.5 我最后想说的
刚开始接触云安全的人，往往会低估 Secret 管理的复杂程度。把密码写进代码、放进环境变量、甚至贴在 Confluence 上……这些我都见过。Secrets Manager 解决的不是技术问题，而是流程和习惯的规范问题。
曾经有个新同事问我：为什么不能直接用 Vault 或者 etcd？我说都可以，但如果你已经在云上，Secrets Manager 内置了 KMS 加密、自动轮换、逐版本审计、资源级策略——这些东西自己搭一遍至少要两周，而且容易留坑。云服务的思想就是「把安全交给平台，把精力留给业务」。
好了，这一章我们明确了 Secrets Manager 是什么、核心概念、适用场景。下一轮我们会深入它的接口规范——毕竟题目就叫《从接口规范看 Secrets Manager 设计详解》，光看概述不过瘾。嗯，但你得先把这些基础概念嚼透，后面才能跟上。