docker镜像层级校验机制通过sha256哈希值（diffid）实现内容寻址验证，拉取时自动比对每层实际内容与manifest声明值，不匹配即中止并报错；chainid确保层间依赖不可篡改；dct等签名机制补全来源可信性。
Docker镜像层级校验机制是防范分发过程中内容篡改的第一道防线，它不依赖标签、不信任网络传输，而是靠每层数据的 SHA256 哈希值“自我证明”——内容一变，哈希即废。这种基于内容寻址的验证方式，让篡改行为在拉取阶段就被自动拦截，无需额外工具或签名也能保障基础完整性。
用 layer digest 实现逐层内容比对
Docker 在拉取镜像时会自动执行三层校验，其中最关键的是对每个 layer 的 diffID 校验： - 每个 layer 下载完成后，Docker 会解压并重新计算其原始文件内容的 SHA256（即 diffID） - 将该值与 manifest 中声明的 diffID 字段严格比对 - 不匹配则中止拉取，并报错 `failed to verify layer integrity`这意味攻击者即使替换某一层（如植入恶意 so 文件），只要内容不同，diffID 就会变化，校验必然失败。你不需要做任何配置，这个过程默认开启且不可绕过。
确保该机制有效运行的关键操作包括：
- 始终使用 完整 digest 拉取镜像，例如
docker pull nginx@sha256:abc...，避免通过 tag（如nginx:latest）间接引用，防止 tag 被覆盖导致指向未知内容 - 构建时禁用
--no-cache以外的跳过策略，确保每一层都真实生成而非复用不可信缓存 - 检查镜像 manifest 是否公开可查：运行
docker inspect --format='{{.RepoDigests}}' 镜像名，确认输出含@sha256:...格式条目
结合 chainID 验证层间依赖关系
diffID 只管单层内容，而 chainID 确保“这层在整条链中的位置”不可伪造。它的计算逻辑是： - 第一层 chainID = 第一层 diffID - 第二层 chainID = SHA256(第一层 chainID + 第二层 diffID) - 后续依此类推这意味着：攻击者不能简单插入或删除某一层，否则后续所有 chainID 都会连锁失效。Docker 启动容器前会依据 manifest 中的 RootFS.Layers 字段，按 chainID 顺序组装 rootfs，并再次校验最终文件系统结构是否与 config blob 描述一致。
你可以手动验证 chainID 连贯性：
- 用
docker history --no-trunc 镜像名查看各层 chainID（显示为 IMAGE ID 列） - 对比
docker inspect 镜像名输出中RootFS.Layers数组，确认其顺序与 history 输出完全一致 - 若某层 chainID 出现在 history 中但不在 Layers 列表里，说明镜像元数据已被破坏
启用内容信任（DCT）补全来源可信性
摘要校验只防“内容改”，不防“人作假”。比如攻击者控制了私有 registry，上传一个完全合法但带后门的镜像，其 digest 依然自洽。此时需叠加数字签名，把“谁签的”和“签了什么”绑定。Docker Content Trust（DCT）通过 Notary v2 协议，在 manifest digest 上叠加签名，并强制客户端验证：
- 设置
export DOCKER_CONTENT_TRUST=1后，docker pull会拒绝未签名镜像 - 签名存储为独立 OCI Artifact，不随镜像自动下载，必须显式触发验证
- 若签名缺失、过期或公钥不匹配，命令直接退出，不写入本地镜像库
生产环境建议组合使用：
- 基础层：用 digest 拉取 + 自动摘要校验，守住内容底线
- 增强层：启用 DCT 或 cosign，绑定构建者身份与时间戳
- 运行层：在 containerd 配置中启用 signature policy，让 runtime 拒绝未签名镜像启动
不复杂但容易忽略。
