企业官网建设流程全解析

CI/CD 密钥治理：流水线越自动，凭证越要收紧

一、自动化流水线最怕凭证到处飞

CI/CD 自动化越完善，流水线能做的事情越多：拉代码、构建镜像、推送仓库、部署集群、发布制品、通知系统。能力越大，凭证风险越高。如果一个长期 token 能从构建一直打到生产集群，泄露后影响面会非常大。

密钥治理不是把变量放进 CI 平台就结束。要看凭证来源、权限范围、生命周期、审计记录和泄露后的撤销速度。流水线越自动，凭证越要短、窄、可追踪。

二、凭证应该按阶段最小化

构建、扫描、发布、部署，每个阶段需要的权限不同。

flowchart TD A[代码检出] --> B[依赖安装] B --> C[构建镜像] C --> D[安全扫描] D --> E[推送制品] E --> F[部署环境] B --> G[只读包源凭证] E --> H[制品仓库写权限] F --> I[环境部署权限]

不要用一个万能凭证贯穿全流程。构建阶段不应该拥有生产部署权限，扫描阶段也不应该拥有写集群权限。

三、密钥要避免落入日志和镜像层

下面是一个风险检查思路。

git grep -n "TOKEN\\|PASSWORD\\|SECRET" . docker history <image> trivy fs .

这些命令不能替代完整治理，但能发现一部分硬编码和镜像层泄露。更可靠的方式是用 CI 平台的 secret 管理、临时凭证和最小权限服务账号。

四、短期凭证比长期 token 更适合流水线

长期 token 最大的问题是生命周期太长。一个月前泄露，今天可能还有效。OIDC 联邦、临时 STS 凭证、按 job 签发的短期 token，会明显降低泄露后的影响。

还要限制密钥可见范围。只有受保护分支、受保护环境和经过审批的 job 才能读取生产凭证。PR 流水线尤其要小心，来自外部贡献的代码不应该接触敏感变量。

审计必须能回答谁在什么时候用什么凭证做了什么。没有审计，密钥治理只能靠信任。出现异常部署、异常推送或异常访问时，追不到 job 和提交，就很难快速止损。

最后，密钥轮换要演练。很多团队写了轮换制度，但从来没真正换过。一旦事故发生，才发现凭证散落在脚本、平台变量和人工文档里。能定期轮换，才说明密钥管理真的可控。

还要给不同环境设置独立凭证。开发、测试、预发、生产共用同一套 token，是非常危险的省事。低环境权限被滥用时，不应该能影响生产；生产凭证也不应该出现在普通调试 job 里。

流水线日志要做脱敏和阻断。即使 CI 平台支持 secret mask，也不能完全依赖它。脚本set -x、工具错误输出、构建参数回显，都可能把凭证片段带出来。关键 job 应该默认关闭命令回显，并对日志做二次扫描。

制品仓库权限也要收紧。能推镜像不代表能覆盖任意 tag。生产部署依赖的 tag 或 digest 应该有保护规则，避免普通流水线覆盖已发布制品。密钥治理和制品不可变性要一起看。

最后，要准备泄露响应清单。发现 token 泄露后，谁吊销、谁排查使用记录、谁重跑发布、谁确认环境状态，都要提前写清楚。事故时再找人，会浪费最宝贵的窗口。

还要区分机器凭证和人员凭证。流水线应该使用专门的服务身份，不要复用个人账号 token。人员离职、转岗或权限变化时，个人凭证会带来额外管理负担，也会让审计结果变得不清晰。

审批也要按环境分级。测试环境可以自动部署，生产环境至少要有受保护分支、变更记录和必要审批。自动化不是取消控制，而是把控制点放到更清晰的位置。

五、总结

CI/CD 密钥治理的原则是短期、最小权限、分阶段、可审计。不要让一个万能 token 贯穿构建到生产。流水线越自动，越要把凭证边界收紧，否则自动化会把一次泄露放大成全链路风险。