镜像签名解决的是“这个镜像是否来自可信构建流程、内容是否被篡改、是否允许进入集群”的问题。仅靠镜像仓库权限并不足以覆盖供应链风险，因为镜像可能在构建、推送、复制、拉取和部署任一环节被替换或误用。通过签名、摘要锁定和准入验证，可以把信任从“我记得这是某个仓库的镜像”提升到“平台可以验证它确实由授权流程产生”。
镜像签名适合解决哪些问题
在容器化交付中，标签是可变引用，app:latest或app:prod可能在不同时间指向不同内容。镜像签名通常基于不可变摘要工作，对特定镜像内容生成签名，并把签名材料存放在仓库或透明日志中。部署时再验证镜像摘要、签名者身份和策略要求，确保未签名或不符合策略的镜像无法进入生产。
镜像签名不是漏洞扫描的替代品。扫描关注镜像里有什么风险，签名关注镜像是不是可信来源、是否在签名后被改变。两者应配合使用：构建完成后先扫描和测试，通过后对镜像摘要签名；部署前验证签名和扫描结果状态。关于镜像治理的基础能力，可结合 https://www.cloudnative-tech.com/container_images/ 做统一规划。
基本流程：构建、签名、验证、准入
以cosign为例，流程可以从本地或CI开始。首先构建镜像并推送到仓库，获取镜像摘要；然后由CI使用受控身份或密钥对摘要签名；最后在部署阶段由准入控制器验证签名。生产环境应尽量避免人工在本地对生产镜像签名，因为这会削弱审计链路。
docker build -t registry.example.com/team/api:1.2.0 .
docker push registry.example.com/team/api:1.2.0
cosign sign registry.example.com/team/api@sha256:xxxxxxxx
cosign verify registry.example.com/team/api@sha256:xxxxxxxx实际流水线中，应把sha256摘要写入发布制品或Helm values，而不是只传递标签。这样即使标签被覆盖，部署系统也能拉取到预期内容。对于多架构镜像，还要确认签名对象是镜像索引还是单架构镜像，避免验证范围与部署范围不一致。
密钥模式与无密钥模式怎么选
传统模式使用KMS、HSM或密钥文件进行签名，优点是控制路径清晰，适合已有密钥管理体系的企业；缺点是密钥轮换、权限分发和泄露处置需要严格流程。无密钥模式则更多依赖CI身份、OIDC和透明日志，减少长期密钥暴露，适合云原生流水线，但需要企业理解并接受身份提供方、日志服务和证书链的信任模型。
无论选择哪种方式，都要回答三个问题：谁有资格签名，什么条件下可以签名，签名记录如何审计。生产镜像不应允许开发者个人随意签名，而应由通过测试、扫描、审批或变更流程后的CI任务签名。签名策略最好绑定仓库路径、分支、构建系统身份和环境级别。
Kubernetes准入验证如何落地
如果只是签名但部署时不验证，镜像签名的价值会大幅降低。集群侧可以通过Kyverno、OPA Gatekeeper、Sigstore Policy Controller或平台内置准入策略验证签名。策略应从生产命名空间开始，要求镜像必须使用摘要、必须存在可信签名、签名者满足预期身份，并可结合漏洞扫描结果阻断高危镜像。
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: verify-signed-images
spec:
validationFailureAction: Enforce
rules:
- name: require-signature
verifyImages:
- imageReferences:
- registry.example.com/team/*
required: true
verifyDigest: true上线准入策略时不要直接全局强制。建议先以审计模式运行，统计未签名镜像、可变标签和第三方镜像来源；再对核心业务命名空间强制；最后把基础镜像、运维镜像和外部依赖纳入例外管理。这样可以避免一次性阻断大量历史工作负载。
供应链安全不止签名
镜像签名应与SBOM、漏洞扫描、构建溯源、仓库权限和部署审计结合。SBOM说明镜像包含哪些组件，扫描说明是否存在已知漏洞，构建溯源说明镜像如何产生，签名说明制品由谁确认可信，准入策略说明什么能进入集群。缺少任何一环，供应链治理都会留下盲区。
对于企业平台，建议把镜像推广到生产的过程标准化：开发构建测试镜像，CI扫描并生成SBOM，发布流水线基于摘要签名，镜像仓库保留不可变制品，Kubernetes准入验证签名和摘要，运行时监控记录实际拉取的镜像。这样才能在安全事件发生时追踪到具体提交、构建任务和部署批次。
常见问题
镜像已经在私有仓库里，还需要签名吗？
需要考虑。私有仓库解决访问控制问题，但不能完全证明镜像内容未被替换，也不能表达“该镜像已通过企业发布流程”。如果仓库账号泄露、标签被覆盖、跨仓库同步出错或人工误推，单靠私有仓库很难在部署时发现。签名加摘要验证能让集群在拉取前确认制品身份，把仓库权限和发布信任分开管理。
镜像签名会不会拖慢发布效率？
合理集成后影响很小。签名和验证通常发生在CI和准入阶段，耗时远低于构建、测试和镜像推送。真正影响效率的是流程设计不清，例如签名需要人工操作、密钥散落在个人机器、策略例外没有管理。把签名放入自动化流水线，并把失败原因清晰反馈给开发者，反而能减少生产环境中的镜像来源争议。
第三方镜像如何处理签名要求？
第三方镜像可以分级治理。关键基础镜像应优先选择官方签名或企业内部重新构建并签名；临时工具镜像应限制命名空间和生命周期；无法验证来源的镜像不应直接进入生产。企业也可以建立内部镜像代理仓库，对外部镜像完成扫描、SBOM记录、重签名和准入白名单管理，从而把外部依赖纳入统一供应链流程。
结论
镜像签名的价值在于把容器交付从“相信仓库和标签”升级为“验证摘要、身份和策略”。落地时应避免只做工具演示，而要把签名嵌入CI、仓库、准入和审计流程。对于生产集群，签名验证与镜像扫描、SBOM和不可变摘要配合使用，才能形成可追踪、可验证、可治理的容器供应链安全闭环。
转载请注明出处：https://www.cloudnative-tech.com/p/7413/
