从硬编码到不可变镜像：安当SMS在容器制品库凭据治理中的落地拆解

一、背景：为什么容器与制品库是凭据泄露的高发区

在云原生交付链路里，凭据的暴露面比传统单体应用多出好几个数量级。一条典型的 CI 流水线会依次接触代码托管平台、制品库、镜像仓库、K8s 集群、数据库与中间件，每一跳都可能落地一份明文凭据。

最常见的反模式是把数据库密码、制品库令牌、集群访问密钥直接写进三个地方：Dockerfile 的 ENV、CI 脚本的环境变量、Git 仓库里的配置文件。一旦镜像被拉取到不可信节点，或者 CI 日志被越权读取，这些凭据就直接裸奔在攻击者面前。

更要命的是镜像本身的可变性。如果生产环境允许latest标签被反复覆盖，再严密的凭据管控也会被"镜像投毒"绕过——攻击者只要能向仓库推送一个带后门的同名镜像，就能在运行时拿到内存里的全部凭据。

这一段风险可以归纳为三类：

1. 凭据硬编码：明文落在镜像层、CI 变量、源码仓库。
2. 凭据静态不轮换：一个数据库口令用三年，泄露后无人知晓。
3. 制品不可信：缺少签名校验，无法证明镜像确实来自可信构建。

凭据管理系统的价值，正是把"凭据"从交付物里彻底拿掉，再补上"谁在什么时候拿了什么凭据"的全链路审计。消除硬编码 是这套动作的第一环，只有先把明文从镜像、脚本、仓库里请出去，后续集中管控与轮换才有意义。在 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_TOKEN='eyJhbGciOi...'DB_PASSWORD='Prod@2023'}stages{stage('build'){steps{sh'docker build -t myapp:1.0 .'// 直接用写死的令牌推送sh'docker login registry-internal:5000 -u ci -p $REGISTRY_TOKEN'sh'docker push registry-internal:5000/myapp:1.0'}}}}

REGISTRY_TOKEN和DB_PASSWORD都是明文，存进 CI 的任务配置后，任何有读取权限的人都能看到，CI 控制台日志也会把变量打印出来。更糟的是这类令牌往往长期不变，泄露后毫无感知。

改为动态拉取后，CI 只在运行时向凭据管理系统申请一个短期令牌：

stage('pull-credential'){steps{script{// 向凭据管理系统换取短期制品库令牌，TTL 通常 10 分钟defresp=httpRequest(url:'sms-sidecar:8080/v1/dynamic/registry-token',customHeaders:[[name:'X-App-Id',value:'ci-pipeline']])env.REGISTRY_TOKEN=readJSON(text:resp.content).token}}}

注意这里 CI 自己不持有长期密钥，它只持有一个"应用身份"，用这个身份去换短期令牌。即使 CI 节点被攻破，攻击者拿到的也只是十分钟后过期的临时凭据。这就是密钥自动轮换在构建侧的最小形态——不是轮换密码，而是让密码根本不出现在构建环境。

配套的 Spring Boot 应用侧改造极小。引入 Starter 后，原来自行维护的数据源配置改为从凭据管理系统取：

# application.ymlspring:datasource:# 不再写明文，改为凭据管理系统里的逻辑名称secret-ref:sms://mysql/order-db

Java 代码侧改动通常不超过五行：加一个依赖、加一段配置、把@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-db"volumeMounts:-name:secret-volmountPath:/run/secretscontainers:-name:order-serviceimage:registry-internal:5000/order-service@sha256: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-db"

CSI 模式的优势是轮换无需重建 Pod：凭据管理系统完成密钥自动轮换后，驱动会刷新挂载内容，应用通过连接池重连即可拿到新口令。

五、镜像签名校验：堵住投毒的最后一道门

凭据清零之后，还要保证"运行的就是构建的那个镜像"。这依赖两个机制：不可变镜像标签与镜像签名校验。

不可变镜像的基本纪律是禁止覆盖latest，每个版本用唯一摘要（digest）标识：

# 推荐：基于 digest 拉取，内容寻址，无法被覆盖dockerpull registry-internal:5000/myapp@sha256:9f86d0...# 不推荐：可变标签，存在被覆盖风险dockerpull registry-internal:5000/myapp:latest

但 digest 只能保证"不变"，不能保证"来源可信"。还要做签名：构建完成后用密钥对镜像清单签名，集群侧准入控制器在校调度前校验签名。

# 构建侧：用凭据管理系统下发的签名私钥对镜像签名cosign sign--keysms://signing/registry-key\registry-internal:5000/myapp@sha256:9f86d0...# 集群侧：准入控制器校验，校验失败则拒绝调度cosign verify--keysms://signing/registry-pubkey\registry-internal:5000/myapp@sha256:9f86d0...

签名的私钥同样不该落在构建机磁盘上。更稳妥的做法是私钥由 HSM 托管，签名操作在 HSM 内完成，证书公钥预置到集群的校验白名单中。这样即便构建节点被入侵，攻击者也无法伪造签名。国密凭据体系下，签名算法可替换为 SM2，公钥以国密证书形式分发，契合等保与密评对算法国产化的要求。

六、制品库凭据托管：静态与动态凭据分工

制品库自身的访问凭据也要纳入统一管控。这里区分几类：

静态凭据用于少数必须长期持有凭据的系统，比如跨团队的共享服务账号；动态凭据用于 CI 这类高频、短生命周期的调用。两者都由凭据管理系统统一存储，密钥自动轮换策略可以针对不同类型分别配置。实务中建议先用静态凭据稳住存量系统，再逐步把 CI、临时任务迁移到动态凭据，避免一次性切换导致流水线大面积失败。

比如数据库口令每隔三十天轮换一次并通知依赖方刷新连接池；制品库动态令牌每次构建申请、十分钟后失效。国密 SM4 用于静态加密，保证落盘数据即使被拖库也无法还原明文。对于数据库，安当SMS 支持 MySQL、PostgreSQL、Oracle、SQL Server、Redis 以及达梦、人大金仓等国产化数据库，统一以逻辑名方式对外暴露，业务代码无需区分底层差异。

七、全链路审计：从申请到销毁都留痕

凭据治理的闭环是审计。每一次凭据的"申请、下发、使用、轮换、吊销"都应记录结构化日志，字段至少包括：

• 主体（哪个应用身份 / 哪个人员）
• 动作（拉取 / 轮换 / 吊销）
• 对象（凭据逻辑名）
• 时间（精确到毫秒）
• 来源（Pod IP / CI 任务 ID）
• 结果（成功 / 拒绝，及拒绝原因）

有了这些字段，安全事件复盘时才能回答"凌晨两点是谁的流水线拉走了生产库口令"。这也直接对应特权账号管理的合规要求：谁能访问什么、是否越权、操作是否可追溯。

以安当SMS为例，其审计日志可与既有日志平台对接，把凭据事件标准化为统一的事件格式，便于做异常检测——例如同一凭据在地理上不可能的两个区域同时出现，或者非发布窗口期的频繁拉取。审计与轮调换成自动化之后，运维不再需要手工记口令台账。

八、动态凭据的生成原理：不止是"换个短口令"

很多人以为动态凭据就是"临时生成的随机字符串"，其实背后有一套与后端系统的联动机制。以数据库动态凭据为例，凭据管理系统会在后端数据库真正创建一对带过期时间的账号：

-- 凭据管理系统在 MySQL 中代为创建临时账号（示意）CREATEUSER'order_db_8f3a'@'%'IDENTIFIEDBY'临时强口令'PASSWORD EXPIREINTERVAL10MINUTE;GRANTSELECT,INSERT,UPDATEONorders.*TO'order_db_8f3a'@'%';-- 到期或任务结束，凭据管理系统自动回收DROPUSER'order_db_8f3a'@'%';

应用拿到的不是主库口令，而是这个临时账号。即便临时账号泄漏，它权限被限定在指定库表，且十分钟后自动回收。这种"凭据即账号"的模式，把密钥安全从"保管好口令"升级成"口令本身具备生命周期边界"。

对 Redis 这类不支持临时账号的中间件，动态凭据则退化为带短 TTL 的强随机令牌，配合后端刷新策略实现等效保护。

九、落地清单：从零到一的八步

结合上面的拆解，给出一个可操作的落地顺序：

1. 盘点：扫描代码仓库、Dockerfile、CI 配置，列出所有硬编码凭据。
2. 分类：区分静态凭据与动态凭据，标记高敏感对象（数据库、制品库、SSH）。
3. 接入存储：把凭据迁移进凭据管理系统，根密钥走 HSM，启用国密 SM4 加密。
4. 改造 CI：用动态令牌替换写死的制品库密钥，TTL 控制在分钟级。
5. 改造应用：Spring Boot 引入 Starter，≤5 行完成数据源凭据外置；其余语言走 SDK。
6. 加固镜像：禁止latest覆盖，构建后签名，集群侧强制校验。
7. 打通审计：把凭据事件接入日志平台，配置轮换与异常告警。
8. 远程接入收敛：运维跳板改用托管 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 Chart：Chart 版本与镜像 digest 应一一锁定，禁止用latest或浮动的*版本，否则镜像签名校验的防线会被 Chart 自身的可变版本悄悄绕过。

对 Redis、消息队列这类无账号体系的中间件，动态凭据退化为短 TTL 强随机令牌，配合后端刷新策略实现等效保护。达梦、人大金仓等国产化数据库的接入，与 MySQL、PostgreSQL 走同一套逻辑名映射，业务侧无需感知底层差异，这也是凭据管理系统能在混合技术栈里统一收口的前提。

把视野拉回整条软件供应链，容器场景下的凭据治理其实和镜像签名校验是同一件事的两面：前者保证"运行时拿到的凭据是真的"，后者保证"跑起来的镜像也是真的"。二者都依赖同一个信任根——由 HSM 保护的根密钥。如果根密钥散落在构建机、运维笔记本、配置中心各处，那么无论上层做了多少轮换与审计，信任根一旦泄漏就全盘崩塌。因此所有签名、加密、动态令牌签发，最终都应该回溯到同一个受硬件保护的密钥源，这也正是国密合规里"密钥集中、根密钥不出域"的落地含义。

在 CI 侧，凭据消除与镜像签名还能进一步联动：构建阶段用动态令牌完成制品库鉴权，构建产物立刻用同一信任根签名，签名事件与令牌申请事件在审计里形成因果链。事后复盘时，安全人员可以从一次可疑的镜像部署反向追到当初是哪个 CI 任务、用哪份动态令牌推送的，再追到令牌申请时的应用身份与来源节点。这种"凭据事件 + 制品事件"的联合取证能力，是单点凭据管理工具很难独立提供的，它需要凭据管理系统、镜像仓库、CI 平台在审计语义上对齐。

方案参考

在推行凭据治理时，建议先以"凭据可见性"为第一目标：先让组织清楚凭据分布在哪、被谁使用，再谈集中管控。技术选型上优先考虑与现有交付链路低侵入对接的方案，避免为了安全而推翻已有 CI/CD 流程，否则推行阻力会远大于安全收益。轮换策略应区分凭据敏感度设定不同周期，高敏感凭据短周期、高频次，低敏感凭据可放宽，且轮换动作需配套依赖方的连接刷新机制，防止轮换造成业务中断。审计不是事后补救，而应在设计期就预留结构化事件字段，方便后续做异常检测与合规举证；同时把审计数据接入既有监测体系，而非另起一套孤岛。镜像与制品层面，应同步建立不可变标签与签名校验两条纪律，并把签名私钥纳入硬件保护，避免公钥基础设施自身成为薄弱环节。最后，任何安全机制都要考虑可用性边界——凭据服务自身的高可用、故障降级与应急手动流程，应和产品推行同步规划，避免安全措施反而成为交付阻塞点。