Secrets管理概述

要说清楚身份认证和 Secrets 怎么联动，咱们得先搞明白一件事——到底什么是 Secrets？为什么非要集中管？我早年刚带团队的时候，就觉得「密码写在配置文件里不就行了」，结果被线上事故狠狠教育过。嗯，这章咱们就把这个基础夯结实。

什么是 Secrets

Secrets 就是那些「打死也不能让别人知道」的敏感数据。最常见的有：

• 数据库密码、缓存密码、第三方服务密钥
• API 、OAuth Client Secret
• TLS/SSL 私钥、SSH 密钥对
• 加密盐、JWT 签名密钥

说白了，任何能让一个系统冒充另一个系统、或者解锁敏感资源的凭证，都是 Secrets。它们有这几个共性：

• 生命周期短——该轮换时不轮换，风险指数级上升
• 极难静态保护——Git 提交历史、日志、环境变量，到处都可能泄露
• 一失万无——一个密钥泄漏，整个集群都可能被攻破

为什么需要集中管理

你可能会说：「每个应用自己管自己的密码不行吗？」我曾经也这么想，直到我们遇到一次内部审计——查了三天都没找全所有数据库密码存在哪。分散管理的问题太典型了：

• 硬编码成灾——配置文件、启动脚本、Dockerfile 里到处是明文密码
• 难以轮换——改一个密码要通知所有相关方，漏一个就炸
• 审计盲区——谁什么时候访问了哪个 Secrets？没人说得清
• 权限混乱——所有人都能读到生产环境密码，安全形同虚设

集中管理后，你能做到：

• 所有 Secrets 存在一个受保护的「保险柜」里
• 每次读取都有审计日志，可追溯
• 权限精细到「哪个应用能读哪个密钥」
• 自动轮换，无需人工介入

Secrets 的类型与风险等级

不同 Secrets 的敏感程度不一样，管理策略也该有差异。我习惯用一个简单表格来分类：

集中管理的核心架构

下面这张图展示了典型的集中式 Secrets 管理架构。你可以看到，应用不再直接持有密码，而是通过认证后从 Secrets Manager 实时读取。

常见工具对比

市场上成熟的 Secrets 管理工具不少，我简单列几个常用的，方便你们选型时参考：

从分散到集中的第一步

如果你现在还是散落管理，别急着一步到位。我个人建议按这个顺序改造：

1. 扫描所有仓库和配置文件，把明文 Secrets 揪出来
2. 选一个集中管理工具（小型团队从 Vault dev 模式起步即可）
3. 把最敏感的数据库密码和 先迁移
4. 配上审计日志，定期审查访问记录
5. 逐步推进自动轮换策略