很多团队的凭据安全建立在"攻击者进不来"的假设上。本文换一个更务实的视角——Assume Breach（假设失陷）：当 Pod 已经被非法盗用，你的架构能否保证数据库凭据不泄露？我们从技术选型维度拆解。
一、传统 Secret 方案的失陷暴露面
先量化风险。当一个挂载了 K8S Secret 的 Pod 被攻陷，攻击者能拿到什么：
| 维度 | 传统 Secret 方案 | 风险等级 |
|---|---|---|
| 口令形态 | 真实口令，base64 可还原 | 高 |
| 有效期 | 永久，直到人工改密 | 高 |
| 存储位置 | etcd 明文 + Pod 挂载文件 | 高 |
| 身份区分 | 多服务共用同一口令 | 高 |
| 行为审计 | 无 | 中 |
| 吊销粒度 | 只能改密，影响所有使用者 | 高 |
结论：Pod 失陷 ≈ 数据库口令泄露。攻击链极短，且缺乏止血手段。
二、选型目标：把"失陷即沦陷"变成"失陷也可控"
选择凭据管理方案时，建议以"失陷场景下的暴露面"为核心评估指标，重点关注四项能力：
1. 动态临时凭据（核心）
业务 Pod 不持有真实口令，需要时向管理系统用自身身份实时申请带 TTL 的临时凭据。Pod 内存里只有几分钟有效期的临时票，攻击者即便读取也无法长期利用。
选型要点：TTL 是否可配、申请是否无需改业务代码、是否支持按身份下发。
2. 自动轮转（核心）
底层真实口令由系统周期轮转，临时凭据随之失效重签，应用无感。选型要点：轮转是否对应用透明、能否设定短 TTL、泄露后是否自动失效无需人工介入。
3. 身份绑定与最小权限
每个 Pod 用 ServiceAccount 身份申请专属、最小权限凭据，失陷后影响被锁死在该身份，无法横向越权。
选型要点：是否支持工作负载身份、权限是否按身份隔离、能否单独吊销某个身份。
4. 审计与即时吊销
每次凭据申请/使用/过期可回溯，异常可被 SIEM 检测；确认失陷可秒级吊销身份，远程切断凭据获取能力。
选型要点：审计日志结构是否可被 SIEM 消费、吊销是否秒级、是否影响其它业务。
三、方案对比：自研 vs 托管凭据管理
| 对比项 | 自研短期令牌 | 引入凭据管理系统 |
|---|---|---|
| 临时凭据 | 需自己实现签发/校验 | 内置，开箱即用 |
| 自动轮转 | 自己写轮转逻辑+应用适配 | 系统托管，应用无感 |
| 身份绑定 | 需对接 K8S 鉴权体系 | 原生支持 ServiceAccount |
| 审计溯源 | 自己落日志 | 结构化审计，可接 SIEM |
| 即时吊销 | 需自建吊销通道 | 管理系统一键吊销 |
| 运维成本 | 高（长期维护） | 低 |
对大多数团队，引入成熟的凭据管理系统在失陷防护上的性价比明显高于自研短期令牌——尤其是"自动轮转 + 即时吊销 + 审计联动"这三项，自研成本高且易留坑。
四、落地检查清单
若你正评估或落地凭据管理，建议对照以下清单：
- [ ] 业务 Pod 不再挂载真实数据库口令
- [ ] 临时凭据 TTL 可按敏感级别配置（高敏业务建议 ≤ 几分钟）
- [ ] 底层口令自动轮转，应用无感
- [ ] 凭据申请按 Pod 身份隔离，权限最小化
- [ ] 审计日志可推送 SIEM，含申请/使用/过期/吊销事件
- [ ] 应急剧本包含"秒级吊销失陷身份"步骤
- [ ] 恢复流程无感（重建 Pod 自动轮出新凭据）
五、结论
云原生凭据安全的关键，不在"把密码藏更深"，而在让密码根本不长期存在于业务侧。通过动态临时凭据消除长驻口令、自动轮转让泄露自然失效，再叠加身份绑定、审计与即时吊销，即可把一次潜在的"数据库全面沦陷"压缩为"分钟级噪声"。
选型时请记住一条铁律：评估凭据方案，不要只看"平时多方便"，更要看"Pod 失陷时有多可控"。
