一、背景为什么容器与制品库是凭据泄露的高发区在云原生交付链路里凭据的暴露面比传统单体应用多出好几个数量级。一条典型的 CI 流水线会依次接触代码托管平台、制品库、镜像仓库、K8s 集群、数据库与中间件每一跳都可能落地一份明文凭据。最常见的反模式是把数据库密码、制品库令牌、集群访问密钥直接写进三个地方Dockerfile 的 ENV、CI 脚本的环境变量、Git 仓库里的配置文件。一旦镜像被拉取到不可信节点或者 CI 日志被越权读取这些凭据就直接裸奔在攻击者面前。更要命的是镜像本身的可变性。如果生产环境允许latest标签被反复覆盖再严密的凭据管控也会被镜像投毒绕过——攻击者只要能向仓库推送一个带后门的同名镜像就能在运行时拿到内存里的全部凭据。这一段风险可以归纳为三类凭据硬编码明文落在镜像层、CI 变量、源码仓库。凭据静态不轮换一个数据库口令用三年泄露后无人知晓。制品不可信缺少签名校验无法证明镜像确实来自可信构建。凭据管理系统的价值正是把凭据从交付物里彻底拿掉再补上谁在什么时候拿了什么凭据的全链路审计。消除硬编码 是这套动作的第一环只有先把明文从镜像、脚本、仓库里请出去后续集中管控与轮换才有意义。在 DevOps凭据 治理语境下这恰恰是 HashiCorp Vault替代 诉求最强烈的场景之一既要兼容现有交付工具链又要满足国密合规。二、整体架构凭据从交付物中剥离以安当SMS为例整套方案的核心思路是凭据不进制品运行时再注入。构建期拿不到明文口令运行期通过 SDK 或 Sidecar 动态拉取且拉取动作全程留痕。架构可以拆成四层凭据存储层根密钥由 HSM 保护业务密钥用国密 SM4 加密存储静态凭据与动态凭据分离管理。注入层K8s 通过 Init Container 或 CSI Provider 在 Pod 启动前拉取凭据Spring Boot 应用引入 Starter 在装配阶段注入。构建层CI 不再持有长期凭据改用短期动态令牌向制品库鉴权。校验层镜像构建完成后做签名集群侧准入控制器强制校验签名后才允许调度。这样镜像层里不再有明文CI 脚本里不再有长期密钥制品库鉴权走动态凭据运行时凭据通过国密通道拉取。密钥安全 从靠人别写错升级成架构上就不可能写进去。需要强调一点加密边界落盘到凭据管理系统的业务密钥并不是直接用 HSM 里的根密钥做整库加密而是采用信封加密Envelope Encryption思路。HSM 内的根密钥只用来加密一层密钥加密密钥KEK真正的业务数据密钥DEK由 KEK 加密后与明文数据分开存储。这样做有两个好处其一根密钥永不出 HSM即使数据库文件整体被拷贝也无法在 HSM 之外解开其二轮换时只需用新 KEK 重新加密 DEK不必重写全部密文运维成本可控。国密 SM4 在这里承担 DEK 对业务凭据的对称加密SM2 承担签名与 KEK 的非对称保护二者在合规语境下形成完整闭环。再谈一个常被忽略的点凭据管理系统本身也是交付链路的一环它的鉴权同样要走身份换令牌而非长期口令。也就是说 CI、K8s、应用三方调用凭据管理系统时各自持有的只是短期、可吊销、带作用域的应用身份而不是一份写死的管理员密码。这种系统之间的凭据也动态化的意识是消除硬编码能否真正闭环的关键。三、CI 凭据消除从环境变量到动态令牌传统的 Jenkins 流水线常写成下面这样问题一眼可见pipeline{agent any environment{// 硬编码的制品库令牌写死在任务配置里REGISTRY_TOKENeyJhbGciOi...DB_PASSWORDProd2023}stages{stage(build){steps{shdocker build -t myapp:1.0 .// 直接用写死的令牌推送shdocker login registry-internal:5000 -u ci -p $REGISTRY_TOKENshdocker push registry-internal:5000/myapp:1.0}}}}REGISTRY_TOKEN和DB_PASSWORD都是明文存进 CI 的任务配置后任何有读取权限的人都能看到CI 控制台日志也会把变量打印出来。更糟的是这类令牌往往长期不变泄露后毫无感知。改为动态拉取后CI 只在运行时向凭据管理系统申请一个短期令牌stage(pull-credential){steps{script{// 向凭据管理系统换取短期制品库令牌TTL 通常 10 分钟defresphttpRequest(url:sms-sidecar:8080/v1/dynamic/registry-token,customHeaders:[[name:X-App-Id,value:ci-pipeline]])env.REGISTRY_TOKENreadJSON(text:resp.content).token}}}注意这里 CI 自己不持有长期密钥它只持有一个应用身份用这个身份去换短期令牌。即使 CI 节点被攻破攻击者拿到的也只是十分钟后过期的临时凭据。这就是密钥自动轮换在构建侧的最小形态——不是轮换密码而是让密码根本不出现在构建环境。配套的 Spring Boot 应用侧改造极小。引入 Starter 后原来自行维护的数据源配置改为从凭据管理系统取# application.ymlspring:datasource:# 不再写明文改为凭据管理系统里的逻辑名称secret-ref:sms://mysql/order-dbJava 代码侧改动通常不超过五行加一个依赖、加一段配置、把Value指向凭据引用。以安当SMS为例其 Spring Boot Starter 的接入成本控制在改 ≤5 行代码业务代码无需感知底层的国密加解密与轮换逻辑。对于已经上线的存量服务这种低侵入改造意味着不需要重写数据访问层。四、运行时注入K8s 侧的两种落地形态CI 侧凭证清零只是上半场运行时 Pod 同样不能带明文。K8s 场景通常有两条主流路径。4.1 Init Container 预拉取在应用容器启动前先跑一个 Init Container 向凭据管理系统要凭据写入共享的临时卷应用容器挂载该卷读取apiVersion:v1kind:Podmetadata:name:order-servicespec:initContainers:-name:fetch-secretimage:sms-init:1.4env:-name:SECRET_REFvalue:sms://mysql/order-dbvolumeMounts:-name:secret-volmountPath:/run/secretscontainers:-name:order-serviceimage:registry-internal:5000/order-servicesha256:9f86d0...volumeMounts:-name:secret-volmountPath:/run/secretsreadOnly:truevolumes:-name:secret-volemptyDir:medium:Memory凭据只在内存临时卷里存在Pod 销毁即消失不会落盘。Init Container 拉取动作本身也会被审计记录。4.2 CSI Provider 动态挂载更现代的做法是用 Secrets Store CSI Driver凭据以文件形式动态挂进容器支持轮换热更新apiVersion:secrets-store.csi/v1kind:SecretProviderClassmetadata:name:sms-providerspec:provider:smsparameters:secretRefs:|- name: mysql-password ref: sms://mysql/order-dbCSI 模式的优势是轮换无需重建 Pod凭据管理系统完成密钥自动轮换后驱动会刷新挂载内容应用通过连接池重连即可拿到新口令。五、镜像签名校验堵住投毒的最后一道门凭据清零之后还要保证运行的就是构建的那个镜像。这依赖两个机制不可变镜像标签与镜像签名校验。不可变镜像的基本纪律是禁止覆盖latest每个版本用唯一摘要digest标识# 推荐基于 digest 拉取内容寻址无法被覆盖dockerpull registry-internal:5000/myappsha256:9f86d0...# 不推荐可变标签存在被覆盖风险dockerpull registry-internal:5000/myapp:latest但 digest 只能保证不变不能保证来源可信。还要做签名构建完成后用密钥对镜像清单签名集群侧准入控制器在校调度前校验签名。# 构建侧用凭据管理系统下发的签名私钥对镜像签名cosign sign--keysms://signing/registry-key\registry-internal:5000/myappsha256:9f86d0...# 集群侧准入控制器校验校验失败则拒绝调度cosign verify--keysms://signing/registry-pubkey\registry-internal:5000/myappsha256:9f86d0...签名的私钥同样不该落在构建机磁盘上。更稳妥的做法是私钥由 HSM 托管签名操作在 HSM 内完成证书公钥预置到集群的校验白名单中。这样即便构建节点被入侵攻击者也无法伪造签名。国密凭据体系下签名算法可替换为 SM2公钥以国密证书形式分发契合等保与密评对算法国产化的要求。六、制品库凭据托管静态与动态凭据分工制品库自身的访问凭据也要纳入统一管控。这里区分几类凭据类型使用方生命周期管控要点静态凭据长期服务账号数月到数年加密存储、定期人工复核、最小权限动态凭据CI 流水线、临时任务分钟级 TTL用完即销、自动过期、不可复用SSH Keys运维跳板、远程接入按人员绑定绑定身份、可吊销、操作留痕根密钥HSM 内部长期不出 HSM、仅做信封加密静态凭据用于少数必须长期持有凭据的系统比如跨团队的共享服务账号动态凭据用于 CI 这类高频、短生命周期的调用。两者都由凭据管理系统统一存储密钥自动轮换策略可以针对不同类型分别配置。实务中建议先用静态凭据稳住存量系统再逐步把 CI、临时任务迁移到动态凭据避免一次性切换导致流水线大面积失败。比如数据库口令每隔三十天轮换一次并通知依赖方刷新连接池制品库动态令牌每次构建申请、十分钟后失效。国密 SM4 用于静态加密保证落盘数据即使被拖库也无法还原明文。对于数据库安当SMS 支持 MySQL、PostgreSQL、Oracle、SQL Server、Redis 以及达梦、人大金仓等国产化数据库统一以逻辑名方式对外暴露业务代码无需区分底层差异。七、全链路审计从申请到销毁都留痕凭据治理的闭环是审计。每一次凭据的申请、下发、使用、轮换、吊销都应记录结构化日志字段至少包括主体哪个应用身份 / 哪个人员动作拉取 / 轮换 / 吊销对象凭据逻辑名时间精确到毫秒来源Pod IP / CI 任务 ID结果成功 / 拒绝及拒绝原因有了这些字段安全事件复盘时才能回答凌晨两点是谁的流水线拉走了生产库口令。这也直接对应特权账号管理的合规要求谁能访问什么、是否越权、操作是否可追溯。以安当SMS为例其审计日志可与既有日志平台对接把凭据事件标准化为统一的事件格式便于做异常检测——例如同一凭据在地理上不可能的两个区域同时出现或者非发布窗口期的频繁拉取。审计与轮调换成自动化之后运维不再需要手工记口令台账。八、动态凭据的生成原理不止是换个短口令很多人以为动态凭据就是临时生成的随机字符串其实背后有一套与后端系统的联动机制。以数据库动态凭据为例凭据管理系统会在后端数据库真正创建一对带过期时间的账号-- 凭据管理系统在 MySQL 中代为创建临时账号示意CREATEUSERorder_db_8f3a%IDENTIFIEDBY临时强口令PASSWORD EXPIREINTERVAL10MINUTE;GRANTSELECT,INSERT,UPDATEONorders.*TOorder_db_8f3a%;-- 到期或任务结束凭据管理系统自动回收DROPUSERorder_db_8f3a%;应用拿到的不是主库口令而是这个临时账号。即便临时账号泄漏它权限被限定在指定库表且十分钟后自动回收。这种凭据即账号的模式把密钥安全从保管好口令升级成口令本身具备生命周期边界。对 Redis 这类不支持临时账号的中间件动态凭据则退化为带短 TTL 的强随机令牌配合后端刷新策略实现等效保护。九、落地清单从零到一的八步结合上面的拆解给出一个可操作的落地顺序盘点扫描代码仓库、Dockerfile、CI 配置列出所有硬编码凭据。分类区分静态凭据与动态凭据标记高敏感对象数据库、制品库、SSH。接入存储把凭据迁移进凭据管理系统根密钥走 HSM启用国密 SM4 加密。改造 CI用动态令牌替换写死的制品库密钥TTL 控制在分钟级。改造应用Spring Boot 引入 Starter≤5 行完成数据源凭据外置其余语言走 SDK。加固镜像禁止latest覆盖构建后签名集群侧强制校验。打通审计把凭据事件接入日志平台配置轮换与异常告警。远程接入收敛运维跳板改用托管 SSH Keys取消长期共享口令所有远程访问走身份绑定。八步里有三类能力是底座要求高安全HSM 根密钥、国密加密、高可用凭据服务不能成为单点、高合规审计可追溯。这三点决定方案能否真正在生产长期运转。十、常见误区误区一把凭据放进镜像但不提交到 Git。镜像一旦推送到仓库任何能拉镜像的人都能docker history看到层里的 ENV等于公开。误区二只在应用层做凭据管理CI 仍然硬编码。攻击者不攻应用直接读 CI 日志拿令牌前功尽弃。误区三用了动态凭据但不设 TTL。没有过期时间的动态和静态没区别泄露后无法自动止血。误区四镜像签名但公钥管理松散。公钥若能被随意替换签名校验形同虚设私钥托管进 HSM 才是正解。误区五审计日志只存本地不告警。能追溯不等于能发现异常模式必须配规则实时触发否则等月度复盘才发现早已被拖库。十一、高可用部署与故障降级凭据管理系统一旦成为所有服务的凭据来源它就从辅助系统变成了关键路径。如果它宕机导致全公司应用起不来安全反而制造了更大的可用性事故。因此高可用必须在设计期就考虑。典型的部署形态是凭据管理服务以多副本状态运行在独立可用区后端加密根密钥由 HSM 集群以主备或多活方式保护。请求侧通过 Sidecar 或本地缓存兜底应用首次拉取凭据后在内存中保留一份解密后的明文并订阅凭据管理系统的轮换事件当凭据管理系统短暂不可达时应用继续使用缓存中的旧凭据直到 TTL 到期或收到轮换通知。这样即便凭据管理系统整体抖动已运行的服务不会瞬间全部失联。故障降级还要区分两种情形其一是凭据管理系统完全不可用此时应允许运维通过受控的应急通道例如带审批的临时文件挂载注入凭据但这次注入同样要被记录其二是部分依赖如 HSM不可用此时可临时切换为软件根密钥模式并告警待硬件恢复后回切。无论哪种降级原则都是宁可慢一步、不可全阻断并且任何绕过正常路径的凭据获取都必须进审计。十二、与既有中间件体系的对接边界凭据治理落地时业务最关心的是现有那一堆中间件要不要改。对数据库类Spring Boot 通过 Starter 把数据源凭据外置改造成本最低对 K8s走 CSI 或 Init Container对 Jenkins 这类 CI走动态令牌。但对 Gitlab Runner、Argo CD、 Helm 这类制品与编排工具凭据注入方式各有差异需要逐个确认其是否支持外部凭据引用。以 Helm 为例values 文件里不应再写明文而是把敏感项交由凭据管理系统在渲染期填充或者使用支持凭据引用的 Helm 插件在模板渲染阶段从凭据管理系统拉取并临时注入。不可变镜像的纪律同样适用于 Helm ChartChart 版本与镜像 digest 应一一锁定禁止用latest或浮动的*版本否则镜像签名校验的防线会被 Chart 自身的可变版本悄悄绕过。对 Redis、消息队列这类无账号体系的中间件动态凭据退化为短 TTL 强随机令牌配合后端刷新策略实现等效保护。达梦、人大金仓等国产化数据库的接入与 MySQL、PostgreSQL 走同一套逻辑名映射业务侧无需感知底层差异这也是凭据管理系统能在混合技术栈里统一收口的前提。把视野拉回整条软件供应链容器场景下的凭据治理其实和镜像签名校验是同一件事的两面前者保证运行时拿到的凭据是真的后者保证跑起来的镜像也是真的。二者都依赖同一个信任根——由 HSM 保护的根密钥。如果根密钥散落在构建机、运维笔记本、配置中心各处那么无论上层做了多少轮换与审计信任根一旦泄漏就全盘崩塌。因此所有签名、加密、动态令牌签发最终都应该回溯到同一个受硬件保护的密钥源这也正是国密合规里密钥集中、根密钥不出域的落地含义。在 CI 侧凭据消除与镜像签名还能进一步联动构建阶段用动态令牌完成制品库鉴权构建产物立刻用同一信任根签名签名事件与令牌申请事件在审计里形成因果链。事后复盘时安全人员可以从一次可疑的镜像部署反向追到当初是哪个 CI 任务、用哪份动态令牌推送的再追到令牌申请时的应用身份与来源节点。这种凭据事件 制品事件的联合取证能力是单点凭据管理工具很难独立提供的它需要凭据管理系统、镜像仓库、CI 平台在审计语义上对齐。方案参考在推行凭据治理时建议先以凭据可见性为第一目标先让组织清楚凭据分布在哪、被谁使用再谈集中管控。技术选型上优先考虑与现有交付链路低侵入对接的方案避免为了安全而推翻已有 CI/CD 流程否则推行阻力会远大于安全收益。轮换策略应区分凭据敏感度设定不同周期高敏感凭据短周期、高频次低敏感凭据可放宽且轮换动作需配套依赖方的连接刷新机制防止轮换造成业务中断。审计不是事后补救而应在设计期就预留结构化事件字段方便后续做异常检测与合规举证同时把审计数据接入既有监测体系而非另起一套孤岛。镜像与制品层面应同步建立不可变标签与签名校验两条纪律并把签名私钥纳入硬件保护避免公钥基础设施自身成为薄弱环节。最后任何安全机制都要考虑可用性边界——凭据服务自身的高可用、故障降级与应急手动流程应和产品推行同步规划避免安全措施反而成为交付阻塞点。