Appearance
Secret 管理怎么接进 CI/CD
CI/CD 里最危险的一类隐患，不是脚本写错，而是敏感信息在构建、日志、制品和部署环节里到处泄漏。Secret 管理的重点不是“能不能读到”，而是“谁在什么阶段可以读到多少”。
先说结论
- Secret 不要写死在代码、流水线 YAML、镜像和制品里
- 构建阶段尽量少接触生产 Secret，部署阶段按环境动态注入
- 流水线必须具备权限隔离、访问审计和轮换能力
- 能用短期凭证就不用长期固定密钥，能按环境分离就不要混用
一、先分清 Secret 会经过哪些阶段
一条典型流水线里，Secret 可能会出现在：
- 拉代码和依赖阶段
- 构建镜像或制品阶段
- 部署和发布阶段
- 运行时容器或进程启动阶段
这几个阶段对 Secret 的需求完全不同。
很多问题就出在：本来只需要部署时读取，却在构建阶段就把生产密钥拿进来了。
二、核心做法
分环境隔离
开发、测试、预发、生产要使用独立 Secret。不要为了省事复用一套账号密码，否则一旦测试日志泄漏，生产也会一起暴露。
分阶段暴露
编译、单测阶段通常不需要生产 Secret；真正需要敏感信息的往往是部署、发布校验和运行阶段。能晚一点注入，就不要提前暴露。
走统一密钥中心
无论是云厂商 KMS、Vault，还是 Kubernetes Secret + 权限体系，都比把变量硬写在 Jenkins、GitLab CI 配置里更稳。流水线只拿临时访问令牌，真正的值从密钥中心动态获取。
三、一条更稳的落地链路
- 开发侧只维护 Secret 名称，不维护明文值。
- 流水线在运行时根据环境和服务名拉取对应密钥。
- 部署工具把 Secret 注入到目标运行环境，而不是写入构建产物。
- 日志默认脱敏，命令回显关闭敏感输出。
- 定期轮换密钥，并验证旧密钥失效是否生效。
如果你在 Kubernetes 上运行服务，更推荐把 Secret 注入放在部署清单或运行时层，而不是在 CI 阶段写入 .env 文件再一起打包。
四、几种常见方案怎么选
1. 云厂商 KMS / Secret Manager
适合云上部署、环境边界清晰、希望统一审计的团队。
2. Vault
适合对权限、租约、动态凭证要求更高的团队，但运维复杂度也会更高。
3. Kubernetes Secret
适合已经把应用都托管在 K8s 上，并且会配合 RBAC、命名空间隔离和密文存储一起使用的团队。
五、常见误区
把 .env 文件直接传进仓库
这是最常见也最危险的泄漏方式，尤其在多人协作和公共仓库场景下。
让 CI 平台永久保存生产密码
长期静态凭证一旦泄漏，影响面很大。优先使用短期 Token、OIDC 或临时授权。
Secret 注入了就算完成治理
如果没有审计、没有轮换、没有最小权限，同样会在生产中留下隐患。
构建镜像时把 Secret 烘焙进去
这会让 Secret 跟着镜像层、缓存和制品仓库长期存在，后面很难回收。
六、上线后至少要补的治理动作
- Secret 访问审计
- 定期轮换
- 环境隔离检查
- 日志脱敏检查
- 流水线变量权限审查
总结
Secret 接入 CI/CD 的关键，不是让流水线“拿得到”，而是让它只在必要阶段、以最小权限、可追踪地拿得到。