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: truedigest 是内容地址比 tag 更可靠。三、部署前要验证cosign verify registry.example.com/appsha256:...验证应该进入部署门禁。未签名、签名不可信、签名主体不匹配的镜像不应该进入集群。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、准入控制、密钥管理和回滚流程。能拉取不代表能运行。生产集群应该只运行能证明来源和内容可信的镜像。