1. Secrets 管理概述

说实话，我第一次接触 Secrets 管理很狼狈。

那会儿在做一个微服务改造项目，团队用 GitLab 存代码，顺手就把数据库密码写在了配置文件里。结果有个实习生把代码 push 到了公开仓库——嗯，两个小时不到，生产库被拖走了三张表。老板找我谈话时我脑子里只有一个念头：这玩意儿早该管起来。

你想想看，Secrets 到底是什么？

不只是密码。、数据库凭证、TLS 证书、云服务 Access Key、SSH 私钥……只要是用来证明身份或解锁敏感资源的数据，都算 Secrets。它们遍布在你的代码、CI/CD 流水线、容器镜像和运行环境里。

那为什么需要专门搞一套管理？直接写在代码里不行吗？

——真不行。我一个个说给你听。

传统方式的五大痛点

下面这张表把传统做法和它们的槽点一次性说清楚：

方式	常见做法	主要风险
硬编码	字符串写死在源代码里	版本控制泄露，重构时遗漏，无法轮换
配置文件	.env / application.yml 带凭证	易被误传、合入仓库、日志打印暴露
环境变量	通过 Shell 或 Docker 传递	变量列表零散，对进程可见，审计困难
密钥文件	直接放在服务器本地磁盘	无加密、无访问控制、备份泄露风险
手动轮转	运维人肉更新密码并重启服务	人为遗漏、恢复慢、产生停机窗口

说白了，传统方式缺了三条腿：集中化、自动化、审计可追溯。

你想想，如果一个团队的 Secrets 分散在十几个微服务的配置里、三个人的个人笔记里、还有 Jenkins 的构建参数里——改个密码至少需要发三封邮件、做两次回滚准备。出了事故都没法查是谁什么时候访问过那个值。

为什么会这样？因为传统方式把 Secrets 当运维残局来收拾，而不是当作一等公民来设计。

云 Secrets 工具的核心价值

我后来在几个云原生项目里陆续试了 HashiCorp Vault、AWS Secrets Manager、Azure Key Vault、Kubernetes External Secrets……慢慢摸清了它们到底好在哪。说白了就四点：

1. 集中控制——所有 Secrets 存在一个统一存储，谁创建、谁访问、谁更新，全链路可查。
2. 自动轮换——设置周期，系统自己换新凭证，应用零停机衔接。我见过一团队把数据库密码设成每6小时自动轮换，没人再喊「改密码改到凌晨3点」。
3. 细粒度策略——可以做到「开发只能读 dev 命名空间、只读、不使用」，比传统 POSIX 权限精细得多。
4. 集成生态——Kubernetes、CI/CD、Terraform、GitOps 工具都能直接对接。

为了让你更直观地理解，我画了一张核心概念图，把从痛点、价值到落地能力的关系串起来：

你看这张图，从上到下串联了 「为什么管 → 痛点与价值 → 工具分类 → 能力 → 目标」。我在好几个团队讲 Secrets 落地时都先画这个框架——团队里有人明白「我们不是为了用工具而用工具，是为了不让人再凌晨爬起来改密码」之后，后面推进就顺多了。

额外说两句

有些朋友会问：直接用云厂商的托管服务不就行了？

嗯，如果你基础架构已经全部上云，那确实方便。但要注意跨云、混合云、多环境场景下的权限模型差异。我见过一个团队因为用了两个不同云厂商的 Secret 服务，结果合规团队要求统一的 audit log——那又是另一番折腾。