镜像签名验证通过绑定内容与发布者身份，在拉取后立即执行内容-身份双重校验，拦截已被篡改的镜像；配合默认启用的layer diffID校验和强制digest拉取，形成不可绕过的三层防护。
镜像签名验证本身不直接防御中间人篡改传输过程中的数据，但它通过绑定内容与发布者身份，在拉取完成后的校验环节彻底拦截已被篡改的镜像——只要篡改发生，签名必然失效，拉取即被拒绝。
签名验证在拉取后立即执行内容-身份双重校验
启用 Docker Content Trust（DCT）或使用 cosign 后，docker pull 不再只是下载数据，而是一个“下载 + 验证”原子操作：
- Docker 客户端从 registry 下载镜像 manifest、config 和各层 blob 后，会向 Notary 服务（或 OCI 注册表中的签名存储）查询该镜像对应的有效签名；
- 用发布者公钥解密签名，还原出原始 manifest 的 SHA256 哈希值；
- 本地重新计算已下载 manifest 的哈希，比对二者是否一致；
- 若不一致（说明 manifest 被替换或修改），或签名无法解密/过期/证书不可信，整个拉取失败并报错
signature verification failed。
配合层级哈希校验，形成双重防护网
即使攻击者绕过签名系统（如伪造一个带签名的假镜像），Docker 默认启用的layer diffID 校验仍会拦截：
- 每层下载解压后，Docker 自动计算其未压缩内容的 SHA256（即 diffID）；
- 将结果与 manifest 中声明的 diffID 字段严格比对；
- 中间人若篡改某一层（例如注入恶意二进制），diffID 必然变化，触发
failed to verify layer integrity错误； - 该机制无需额外配置，不可禁用，是内置于容器运行时的基础防线。
强制使用 digest 拉取，切断 tag 被劫持的风险链
中间人常通过污染 DNS 或镜像仓库 tag 映射来实施攻击（如把 nginx:latest 指向恶意镜像）。签名验证要真正起效，必须配合明确的内容寻址：
- 始终用完整 digest 拉取：
docker pull nginx@sha256:7e...，而非依赖易变的 tag； - CI/CD 流水线中禁止使用
:latest或模糊 tag 构建或部署； - Kubernetes Pod spec 中 image 字段应固定为
@sha256:...格式，避免 runtime 解析 tag 带来的不确定性。
信任锚必须可信且受控
签名验证是否有效，取决于你信任谁的公钥：
- 默认情况下，Docker 客户端信任 Docker Hub 的根证书；私有环境必须部署自己的 Notary 服务或兼容 TUF 的签名后端，并将 CA 证书加入 daemon 信任链（
/etc/docker/certs.d/）； - 禁用不安全的 HTTP registry 或自签名证书直连（除非显式配置信任）；
- 根密钥必须离线保管，委托密钥需按角色最小化分发，防止私钥泄露导致全量签名失效。
