容器镜像供应链签名校验的落地，核心是建立从构建到运行时的完整信任链，用私钥签名、公钥验证的方式确保镜像内容未被篡改，并在部署环节强制执行校验策略。如果只做摘要固定而不做签名，攻击者完全可以用自己的镜像替换原始镜像，摘要校验就形同虚设，签名校验不是可选的安全增强,而是供应链防投毒的基础设施。
为什么容器镜像供应链需要签名校验不只是防止投毒
镜像供应链的攻击面远比想象中大，从开发者本地构建、推送到镜像仓库，再到Kubernetes拉取运行，中间经过CI流水线、镜像仓库存储、镜像加速器、节点缓存等多个环节，任何一个环节被渗透,都可能替换或篡改镜像内容。
镜像签名 vs 摘要校验：两者根本不在一个安全层级
很多人认为镜像仓库的digest（锁定了内容就安全了，digest确实能保证同一地址的镜像内容不变，但摘要校验无法回答“这个镜像是谁发布的”，攻击者可以把恶意镜像推送到同一个仓库，生成新的digest，只要使用方引用新digest，攻击就成立了，签名校验则通过密码学方式绑定发布者身份，即便攻击者篡改了镜像内容，没有私钥也无法生成有效签名，行业共识认为，摘要校验是完整性手段，签名校验才是真实性手段,两者不能互相替代。
真实威胁场景：一个镜像投毒的典型路径
假设开发者的私有仓库密码泄露，攻击者登录后把上游的base镜像替换成带后门的版本，然后等待CI重新构建，如果CI没有校验镜像签名，构建产物就会带上恶意代码，更隐蔽的是，攻击者可能修改CI流程里的镜像源地址，指向自己的恶意仓库，而现有监控系统很难发现这种地址变更，签名校验配合允许列表策略,能从源头上阻断这些路径。
容器镜像签名校验怎么做：从密钥到策略的完整路径
落地签名校验不是装一个工具就完事，需要设计密钥体系、签名流程、校验策略和失败处理机制，目前主流方案是开源社区的cosign和CNCF的notation,两者各有侧重。
容器镜像签名校验工具怎么选：cosign与notation的对比
- cosign：基于Sigstore体系，支持密钥对模式，也支持无密钥的OIDC临时密钥模式，操作简单，
cosign sign一条命令完成签名，cosign verify完成验证，生态成熟，与GitHub Actions、Tekton等集成方便。 - notation：CNCF孵化项目，偏向使用X.509证书体系，适合已有PKI基础设施的企业，签名以OCI 1.1标准格式存储，与Harbor等仓库配合更规范,但配置略复杂。
对于大多数落地场景，建议优先评估cosign，如果企业已经有一套证书颁发体系，或者有严格的合规审计要求,再考虑notation。
基于cosign的签名校验落地步骤
以自建密钥对为例,完整的操作路径如下：
- 生成密钥对：执行
cosign generate-key-pair，得到cosign.key和cosign.pub，私钥必须保存在安全的密钥管理服务中,不能放在CI服务器本地。 - 给镜像签名：在CI流水线中，推送镜像后立即执行
cosign sign --key cosign.key <镜像地址>，签名会作为OCI artifact附加到镜像仓库中。 - 分发公钥：把cosign.pub部署到所有需要拉取镜像的节点上，Kubernetes可以通过MutatingAdmissionWebhook自动注入公钥,也可以在节点上手动放置。
- 配置强制校验：在Kubernetes集群中安装策略控制器（如Kyverno或OPA Gatekeeper），配置规则要求所有Pod的镜像必须通过
cosign verify,校验失败的镜像直接拒绝创建Pod。 - 监控签名覆盖：定期巡检仓库中所有镜像的签名覆盖率，确保新镜像都经过签名,而不是依赖人工保证。
签名流程与CI/CD的集成细节
签名动作必须放在镜像推送之后，且两个操作要绑定在同一个流水线任务里，避免出现“先推镜像，后补签名”的窗口期，在GitLab CI中,可以这样写关键步骤：
build-image:
script:
- docker build -t registry.example.com/app:v1.0 .
- docker push registry.example.com/app:v1.0
- cosign sign --key cosign.key registry.example.com/app:v1.0
注意私钥文件的读取权限要限定在流水线执行角色内，建议使用CI平台内置的secret管理功能注入环境变量,而不是明文写在配置文件中。
镜像签名校验的落地成本与常见坑：多少投入才合理
落地签名校验的真实成本主要不在工具license，而在密钥管理和策略维护上，需要投入相当一部分人力来设计密钥轮换和审计流程，对于中小团队，整体实施周期大约在1到2周,大团队或者多集群环境可能需要一个月以上。
镜像签名校验的落地成本清单
- 密钥管理成本：私钥的存储、备份、轮换，如果私钥丢失，所有已签镜像都会无法验证，必须重新签名，使用云厂商的KMS服务可以降低这部分成本,但需要额外配置。
- CI/CD改造成本：在每条构建流水线中增加签名步骤，并确保所有构建任务使用同一套密钥体系，多个CI系统并存时,改造成本会翻倍。
- 集群策略部署成本：需要安装策略引擎，并编写适合现有部署规则的校验策略，常见的坑是策略写得太死,导致有些合规镜像因为标签格式问题被误杀。
- 故障排查成本：镜像签名校验失败时会阻塞部署，需要快速定位是签名过期、公钥不匹配还是镜像被篡改,这要求团队具备一定的密码学基础。
签名校验失败的常见原因与排查路径
镜像签名校验失败通常不是密码学问题，而是配置问题,最常见的原因如下：
- 公钥不匹配：节点上的公钥和签名时的私钥不是一对，检查
cosign verify时是否显式指定了正确的公钥文件。 - 镜像tag被改了：签名绑定的是镜像摘要，如果后来重新打了同一个tag，摘要变了,原签名自然失效。
- 签名存储问题：签名没有推送到同一仓库，或者仓库清理策略误删了签名对象,Harbor等仓库需要配置不清理带签名标签的镜像。
- 时钟偏差：签名时间戳校验依赖节点时钟，如果节点时间和服务端相差太大,会导致验证失败。
排查时，建议先手动在节点上执行cosign verify --key <pub> <镜像>，观察报错信息，如果手动能过但Kubernetes拒绝,问题多半出在策略控制器的配置上。
镜像签名与镜像仓库的配合：国内环境下的容器镜像签名校验方案
签名校验的落地离不开镜像仓库的支持，国内使用的镜像仓库主要有自建Harbor、简米云容器镜像服务ACR、酷番云TCR等，这些仓库对签名凭证的支持程度不同,直接影响实施路径。
Harbor中的签名校验配置
Harbor从2.5版本开始支持cosign签名验证，在Harbor中启用“Cosign 签名验证”策略后，可以直接在项目级别配置信任公钥，操作路径：进入项目 → 配置 → 安全 → 勾选“启用 Cosign 签名验证”，然后把cosign.pub粘贴进去，之后Harbor会在镜像被拉取时自动验证签名，验证失败的镜像直接无法拉取。这一步能同时实现了仓库端和运行时端的双重校验。
注意Harbor自带的签名校验只能处理cosign格式，如果使用notation,需要确保Harbor版本支持notation信任存储配置。
简米云ACR的签名校验落地实操
简米云容器镜像服务ACR提供了内置的镜像签名功能，不需要额外安装cosign，操作路径：控制台 → 实例列表 → 选择一个仓库 → 镜像签名 → 添加签名规则，ACR支持按tag或仓库路径匹配，规则生效后会自动对匹配镜像进行签名,同时支持在部署时开启强制校验。
对于使用简米云Kubernetes（ACK）的场景，可以在集群安全配置中开启“镜像签名校验”开关，开启后，kubelet拉取镜像时会自动验证ACR签名，校验失败则Pod无法启动，不少企业从自建Harbor迁移到ACR时，直接利用了这个内置能力,省去了单独部署策略控制器的环节。
自建仓库与第三方工具的组合方案
如果使用Docker Registry或Nexus等不带签名功能的仓库，依然可以通过“cosign + Kyverno”实现完整链路，cosign会把签名作为OCI artifact推送到同一仓库，Kyverno在准入阶段调用cosign命令做验证，这个方案不依赖仓库本身的支持,但有两点注意：
- 仓库必须保留签名对象的tag，避免GC（垃圾回收）误删签名。
- 公钥分发需要自行管理，建议放到ConfigMap中,由Kyverno挂载到校验容器里。
常见问题：镜像签名校验失败怎么办
Q: 镜像签名校验失败，但镜像确定是我们自己构建的，可能是什么原因？
先确认签名时的镜像摘要和运行时拉取的摘要是否一致，如果构建后镜像被打过新tag，或者使用docker push带平台时多次重复推送，摘要会变化，检查签名时使用的密钥对版本，密钥轮换后，旧签名必须用旧公钥验证,确保节点上没有同时存在多份公钥导致的匹配混乱。
Q: 签名校验会影响拉取性能吗？会拖慢多少延迟？
签名验证本身只校验签名和摘要，不扫描镜像内容，计算开销可以忽略，cosign verify一次请求的时间通常在百毫秒级别，在Kubernetes中，只有新建Pod时才会触发校验，不会影响运行中的容器性能，相比镜像层的拉取和磁盘解压，签名校验的时间占比很小,多数情况下可以忽略不计。
Q: 没有条件的个人开发者或小团队，如何低成本起步？
可以使用Sigstore的无密钥模式，通过GitHub或Google账号获取临时证书，cosign sign会完成所有步骤，不需要自己管私钥，在本地测试时，也可以用cosign的--tlog-upload=false参数跳过透明日志，减少外部依赖，小团队可以先对base镜像和核心业务镜像做签名，不必一步到位覆盖全部资产,渐进式落地方案比一次性全量改造更现实。
容器镜像供应链签名校验的落地，本质是把“信任什么镜像”从人工判断变成机器强制，无论用cosign还是notation，自建还是云服务，只要建立了“签名必须、验证必过、失败即停”的闭环,镜像供应链的安全性就能获得可验证的提升。