1、课程导论：密码改造的背景、目标与CI/CD安全概述

先聊个痛。我加入上家公司的第一个月，就被拉进一个安全漏洞复盘会。数据库密码明文写在配置文件里，版本库一拉，谁都能看见。更离谱的是，那个密码三年没换过——离职员工手里还攥着生产环境的钥匙。你说吓不吓人？

这种事儿在中小团队里太常见了。密码硬编码、定期轮换靠人工、泄露了还没法追溯…说白了，很多团队根本没有密码治理的概念。但当我们开始推CI/CD流水线，问题就更尖锐了——

• 测试环境、预发环境、生产环境的密码都塞在同一个仓库里
• Jenkins构建时直接暴露密钥
• 容器镜像里躺着明文凭据

这就不只是“不规范”了，而是把后门焊死在门上。

为什么要搞密码改造

你先想想看：现代应用依赖多少种密码？数据库、、SSH私钥、第三方服务…少说几十个。一旦某个泄露，攻击者可能直接拿到数据或控制权。

我当年接手过一个遗留系统：生产库密码写死在Java代码里，编译后丢在classpath中。运维说“我们都这样好几年了，没事儿”。结果有一次git历史被扫出来，密码直接挂到暗网。那次事故后，CTO才下了死命令——必须改造。

所以说，密码改造的直接驱动力是安全合规（等保2.0、PCI-DSS、GDPR都要求密钥管理），但更深层的目标是自动化与可审计。你想想，如果密码轮换需要人工去改配置文件、再提交发布，那基本等于没做——没人愿意半夜爬起来换密码。

痛点	后果
硬编码密码	泄露即失控，难以追踪
缺少自动轮换	密码长期有效，风险窗口无限大
无审计日志	泄露后不知道谁摸过、什么时候摸的
CI/CD流水线中明文传递	构建日志、制品仓库都可能留下痕迹

改造目标：安全、自动、可追溯

目标其实很清晰：

1. 动态化——密码不落盘，需要时从安全仓库动态获取。
2. 自动化——轮换、更新都由流水线或自动化任务完成，零人工介入。
3. 审计化——每次访问密码都有记录，谁、何时、为什么请求。

这三个目标需要CI/CD流水线深度配合。我们不能把安全当外挂——等代码打包完了再去扫一次，那样迟了。安全要左移，从开发阶段就开始管。

我记得有一次帮一个团队改造他们的Jenkins pipeline。原来他们每次构建都执行一个shell脚本，里面硬编码了数据库地址和密码。我建议换成Vault动态凭据，一开始他们觉得“学新东西浪费时间”。但当我演示完：每次构建自动申请一个临时数据库账号，用完自动回收，他们眼睛都亮了。

CI/CD安全概述

聊完密码改造的目标，我们再看安全本身。很多人觉得CI/CD安全就是“代码不被篡改、制品不被投毒”。其实远不止。流水线本身就是攻击面——

• 凭证泄露：Jenkins的Credentials Plugin如果配置不当，凭据在日志里全会暴露
• 供应链攻击：第三方依赖、Docker镜像可能包含后门
• 权限滥用：给每个job太高权限，一旦被注入，可以横向扩散

为什么会这样？因为CI/CD系统天生需要访问各种敏感资源：代码库、制品库、云服务、生产环境。如果我们不把密码改造纳入安全左移的范围，等于把钥匙挂在门上。

我在一家FinTech公司时遇到过这种情况：他们的GitLab CI runner跑在root权限上，每次构建都挂着Kubernetes集群的kubeconfig。结果一个小白开发者在测试分支里写了个sleep 9999，runner退出前没清理临时文件，其他co-worker就能读到集群凭据。

本章知识体系

为了让你对整体脉络有个直观印象，我画了张图。你可以把它当作后续步骤的地图：

这门课怎么安排

30章的内容，我会带你把密码改造从理论到落地走一遍。你会学到：

• 如何评估现有密码治理成熟度
• 常见的密码存储方案对比（Vault、AWS Secrets Manager、Kubernetes Secrets）
• 在GitLab/GitHub Actions/Jenkins流水线里集成动态凭据
• 自动化轮换脚本怎么写、怎么测
• 安全审计日志如何打通告警和SIEM

嗯，这一章是引子。接下来的每一章都会带着具体的场景、代码、配置文件。你要是现在就想实践，可以先检查下你们团队的项目里有没有明文密码——我保证会找到几个惊喜。