第 2 章：常见 Secrets 类型——你每天都在用，但未必真正了解
聊到 Secrets 管理，咱们先得搞清楚到底要管什么。很多人一上来就纠结用什么工具，结果连自己手里有多少种秘密都说不清。我刚开始干运维那会儿，也踩过这个坑——觉得 Secrets 不就是密码嘛，后来被一个凭据泄露的事故狠狠敲了一棒。
说白了，Secrets 就是任何能帮你通过身份验证、访问受保护资源的敏感信息。它们五花八门，但核心就那么几类。今天咱们一个个捋清楚，顺便说说我踩过的雷。
2.1 密码（Password）——最古老也最危险的秘密
密码是最常见的 Secrets，也是一切混乱的源头。你想想看，公司里有多少个系统？OA、邮箱、GitLab、Jenkins、数据库……每个都要密码。结果就是：要么记不住，要么全设成一样的。
我个人习惯是：坚决不用同一个密码跨系统。但现实里，我见过太多团队把数据库密码写在配置文件里，明文提交到 Git 仓库。有一次我帮客户做安全审计，在 GitHub 上随便搜了一个项目的提交历史，居然找到了生产环境 MySQL 的 root 密码……那个项目还是公开仓库。
- 长度 ≥ 12 位，包含大小写字母、数字、特殊字符
- 每个系统单独生成，不重复使用
- 定期轮换（建议 90 天）
- 不写到代码或配置文件里
2.2 （）——现代服务的大门钥匙
说白了就是一个令牌字符串，用来标识调用方身份。你调用阿里云、AWS、 的接口，都得带上它。它比密码更灵活——可以设置权限范围、过期时间，甚至可以单独撤销。
但我遇到过最离谱的事：某团队把云厂商的 直接硬编码在移动 App 的源码里，结果被反编译，密钥泄露，当月账单多了十几万。为什么？因为 一旦暴露，攻击者就能模拟你调用所有付费服务。
2.3 SSH 密钥——远程登录的免密利器
SSH 密钥对由公钥和私钥组成。公钥放在服务器上，私钥留在本地。登录时，服务器验证你是否有对应的私钥。相比密码，它更安全，也更方便用于自动化运维。
我记得有一次帮朋友排查服务器被入侵的问题。发现他把自己私钥的备份放在了 Dropbox 共享文件夹里，而那个文件夹的链接被分享到了公开论坛……后果可想而知。私钥一旦泄露，攻击者就能以你的身份登录任何配置了对应公钥的机器。
这里有个硬规则：私钥永远不能离开生成它的设备。你可以用 SSH Agent 转发，但别复制私钥到处放。
2.4 证书（Certificate）——TLS/SSL 的信任根基
证书是 PKI（公钥基础设施）的核心。它包含公钥、颁发者、有效期等信息。常用的场景：HTTPS 证书、客户端认证证书、代码签名证书。
证书的麻烦在于：它有过期时间。我曾经在一个项目里，凌晨三点被报警叫醒——生产环境的 HTTPS 证书过期了，用户访问全报安全错误。当时我还没有做自动续期，只能手忙脚乱地重新签发、部署、重启服务。从那以后，我所有的证书都强制提前 30 天自动续期，并且每天检查过期时间。
- 私钥存储必须加密，权限最小化
- 证书到期前自动告警（至少提前 30 天）
- 使用 ACME 协议（如 Let's Encrypt）实现自动续签
2.5 （令牌）——无状态的临时凭证
是密码的进化版。最常见的 JWT（JSON Web ）包含了用户信息和签名，服务器不需要存储 session，就能验证身份。但 有个致命弱点：它一旦签发，在有效期内无法撤销（除非你维护黑名单，那就失去了无状态的优点）。
我见过不少团队把 JWT 的过期时间设成一年，甚至永久。这等于把大门钥匙直接给了别人，而且永远不会自动换锁。正确的做法是： 有效期尽量短（比如 15 分钟），配合 Refresh 使用。
| 类型 | 存储方式 | 常见风险 | 我的建议 |
|---|---|---|---|
| 密码 | 数据库/内存 | 弱口令、复用、明文存储 | 用密码管理器，开启 MFA |
| 配置文件/环境变量 | 硬编码、泄露到代码仓库 | 用 Secrets Manager 动态获取 | |
| SSH 密钥 | 用户目录 ~/.ssh | 私钥泄露、未加密 | 加入密码（passphrase）+ 硬件令牌 |
| 证书 | 文件系统 / HSM | 过期、私钥泄露 | 自动续签 + 监控过期时间 |
| 浏览器 / 客户端存储 | 长有效期、不可撤销 | 短有效期 + Refresh |
2.6 其他你可能会遇到的 Secrets
除了上面五种，还有几种不太常见但同样重要的：
- OAuth2 Client Secret：用于后端服务交换用户授权，一旦泄露可冒充应用。
- 数据库连接字符串：包含用户名、密码、主机、端口，泄露等于数据库裸奔。
- 加密密钥：用于数据加密解密，比密码更基础，丢了就再也解不开数据。
- CI/CD 变量：比如 Jenkins 凭证、GitHub Actions 的 secrets，通常包含云厂商密钥。
我建议：只要能被用来“证明身份”或“访问资源”的敏感字符串，都应该视作 Secrets，纳入统一管理。
2.7 避坑指南：我替你们试过的错
说实话，上面每一种 Secrets 我都踩过坑。这里分享几个真实的“病历”：
- 密码复用：我曾经把测试环境和生产环境用同一个密码，结果测试环境被攻破，生产跟着遭殃。从那以后，我强制每个环境用不同的凭据，并且用 Vault 自动生成。
- 明文保存：一个同事把 AWS 密钥写在 Python 脚本里，脚本上传到 GitLab 私有仓库。后来仓库权限配置错误，被外部爬虫抓走，一夜之间开了上百台挖矿实例。账单我到现在还记得——8 万美金。
- SSH 私钥不带密码：很多开发者觉得每次输 passphrase 麻烦，干脆为空。这等于你把家门钥匙挂在门外。至少加个密码，用 ssh-agent 缓存即可。
- 证书忘记续期：上面说过了，凌晨三点的教训太深刻。现在我用 certbot 自动续签 + 监控告警，才算解脱。
- JWT 不过期：一个内部系统的 有效期设为一年。后来有人离职， 没回收，几个月后系统被异常访问。从那以后所有 默认 15 分钟，配合 Refresh 。
| 代码仓库 | 配置文件、提交历史、环境变量文件（.env） |
| CI/CD 流水线 | 构建脚本、部署脚本、凭据变量 |
| 容器镜像 | Dockerfile 里的 ENV、镜像层里的历史命令 |
| 日志文件 | 打印出来的请求参数、调试输出 |
| 备份文件 | 未加密的数据库备份、配置文件副本 |
| 协作工具 | Slack/飞书里粘贴的密钥、Wiki 页面 |
嗯，以上就是常见的 Secrets 类型。每一种都有自己的脾气。密码简单但容易弱，灵活但容易硬编码，SSH 密钥方便但私钥难保管，证书信任度高但会过期， 无状态但难撤销。没有银弹，只有场景化的管理策略。