Docker 镜像签名：能拉取不代表能运行

一、镜像可信不能只靠仓库地址

容器镜像是云原生交付的核心载体。很多团队默认“从公司镜像仓库拉下来的就可信”，但镜像可能被错误覆盖、供应链污染、tag 被重用、构建过程被篡改。镜像能拉取，不代表它应该被运行。

镜像签名的目标，是证明镜像来自可信构建链路，并且内容没有被替换。

二、先建立签名链路

flowchart TD A[源码提交] --> B[CI 构建镜像] B --> C[生成 SBOM] C --> D[镜像签名] D --> E[推送仓库] E --> F[部署前验证]

签名最好发生在 CI 构建完成后，并和镜像 digest 绑定。不要只签 tag，因为 tag 可以移动。

image_security: sign_by_digest: true verify_before_deploy: true require_sbom: true

digest 是内容地址，比 tag 更可靠。

三、部署前要验证

cosign verify registry.example.com/app@sha256:...

验证应该进入部署门禁。未签名、签名不可信、签名主体不匹配的镜像，不应该进入集群。

Kubernetes 可以通过准入控制实现这一点。比如使用 admission webhook，在 Pod 创建时检查镜像签名。

四、签名策略要可运营

签名不是一次配置。密钥怎么管理，谁有签名权限，密钥泄露怎么轮换，旧镜像如何处理，都要有流程。

signing_policy: key_rotation_days: 90 signer_identity_required: true revoke_compromised_key: true

还要区分环境。开发环境可以允许临时镜像，生产环境必须严格验证。策略一刀切会影响效率，完全放开又没有安全意义。

SBOM 也很重要。签名证明镜像没被换，SBOM 说明镜像里有什么。漏洞扫描、许可证检查、依赖追踪都离不开它。

最后，镜像签名要和回滚兼容。旧版本镜像也必须保留签名和元数据，否则事故回滚时会被安全门禁挡住。

签名策略还要覆盖基础镜像。业务镜像签了名，但基础镜像来自不可信来源，供应链仍然有洞。CI 应该锁定基础镜像 digest，并记录它的漏洞扫描结果。

base_image_policy: pin_by_digest: true require_vulnerability_scan: true block_critical_cve: true

镜像 tag 也要治理。latest不适合生产部署，因为它无法解释到底运行了什么内容。生产环境应该使用不可变 tag 或 digest。

最后，签名验证失败时要给出清晰原因。是没有签名、签名者不可信、digest 不匹配，还是证书过期？原因清楚，开发者才能修复，而不是绕过门禁。

准入策略还要支持例外流程，但例外必须短期有效。比如紧急修复时允许临时放行某个镜像，也要记录原因、审批人和过期时间。没有过期时间的例外，会慢慢变成新的默认规则。

signature_exception: require_reason: true require_approver: true expire_hours: 24

同时，镜像仓库要启用不可变 tag。签名和准入都做了，如果 tag 能被覆盖，排查和回滚仍然会混乱。生产镜像应该靠 digest 定位内容。

最后，镜像签名要接入发布报告。每次上线都能看到镜像 digest、签名主体、SBOM 位置和扫描结果，安全信息才不会散在多个系统里。

五、总结

Docker 镜像签名要绑定 digest，接入 CI、SBOM、准入控制、密钥管理和回滚流程。

能拉取不代表能运行。生产集群应该只运行能证明来源和内容可信的镜像。