DevOps 的初衷是"快速、自动化"，但它在无意间把凭据泄露的风险也自动化了。
一、流水线为什么是凭据泄露重灾区
在 CI/CD 里，凭据通常出现在两个地方：
- Jenkins Pipeline：密码明文写在
Jenkinsfile或 job 配置里，提交即入库； - Kubernetes Secret：数据库密码以 Secret 形式注入，随镜像和 YAML 扩散到各个节点。
问题在于，凭据一旦进入镜像或配置文件，就会跟着制品"到处跑"——构建节点、镜像仓库、测试环境、生产集群，每一处都多一份明文副本。泄露面随节点数指数级放大。
二、核心原则：凭据不落盘
DevOps 凭据安全的根本原则，和消除硬编码一致：凭据只存在于内存，绝不写入磁盘、不进镜像。
落到具体技术，有两个成熟做法：
1. Kubernetes：Service Account 绑定 + Sidecar 注入
Pod 启动时，由凭据系统验证 Pod 身份，动态下发数据库凭据，采用 Sidecar 内存注入模式——凭据仅存在于容器内存中，绝不落盘写入磁盘。这样镜像里永远不含明文密码，从根本上杜绝凭据随镜像扩散。
2. Jenkins：Pipeline 走 REST API
构建脚本不直接写密码，而是在运行时通过 REST API 向凭据系统安全调用，构建过程全程无明文传输。凭据在使用时才被拉取，用完即释放。
以安当 SMS 的 DevOps 集成能力为例，它提供 K8s 集成（与 Service Account 绑定、Sidecar 内存注入）与 Jenkins 集成（Pipeline 通过 REST API 调用）两条路径，目标都是让凭据在 CI/CD 全链路中"不落盘、不扩散"。
三、落地要注意的三个坑
- 别把凭据塞进环境变量就以为安全了：环境变量对同容器进程可见，仍可能残留。内存注入 + 用完释放更稳妥。
- 镜像扫描要覆盖凭据：很多团队做了镜像扫描却漏掉 Secret，等于形同虚设。
- 权限要跟着身份走：Pod 用什么身份取凭据，应当绑定 Service Account，而非共享一个全局令牌。
四、度量是否真的"零明文"
一个简单自检：把你的镜像拉下来grep一遍密码，还能找到吗？能找到，说明还有落盘；找不到，才算过关。这个检查应当写进流水线的门禁，而不是靠自觉。
方案参考
安当 SMS 凭据管理系统提供面向 DevOps 的集成组件，包括 Kubernetes Sidecar 内存注入模式与 Jenkins REST API 调用方式，帮助团队在不改发布习惯的前提下消除流水线明文凭据。对正被"Git 仓库明文密码""镜像带秘钥"困扰的团队，可作为整改参考。
注：本文为技术解析，具体接入方式与兼容性请以官方文档 doc.andang.cn 为准。
