使用镜像 digest（如 sha256:abc123...）可彻底规避 tag 被篡改风险，因其是基于 manifest 内容生成的不可变唯一哈希；tag 仅为可写指针，易被覆盖；digest 在拉取、运行、构建部署全流程校验内容一致性，并结合 Docker Content Trust 验证发布者身份。
直接用镜像 digest（如 sha256:abc123...）拉取和运行，就能绕过 tag 的可变性，从根本上规避 tag 被篡改的风险。
理解 tag 为什么会被篡改
tag 本质是 registry 上的一个可写指针，不是数据本身。运维人员、CI/CD 脚本甚至恶意攻击者都可以重新 docker push 同一个 tag，让它指向完全不同内容的镜像。比如 myapp:prod 昨天指向安全版本，今天被覆盖成带后门的镜像——但所有用 docker pull myapp:prod 的服务都会静默拉到新版本。
用 digest 替代 tag 进行精准定位
每个镜像构建完成后，Docker 会为它的 manifest（描述层、配置、架构的 JSON 文件）计算唯一 SHA256 值，即 digest。这个值由内容决定，不可修改，也不可重定向：
-
拉取时锁定内容：执行
docker pull myapp@sha256:9f86d08...，客户端会校验 registry 返回的Docker-Content-Digest响应头是否匹配，不一致则中止 -
运行时绑定真实状态：容器启动前，Docker 会按 manifest 中的 layer chainID 顺序叠加 rootfs，并重新计算最终文件系统哈希，与 config 中记录的
rootfs.diff_ids交叉验证 -
构建和部署链路可追溯：CI 流水线在构建完镜像后，立即读取
docker inspect --format='{{.RepoDigests}}' myapp:build-123提取 digest，写入部署清单或 K8s YAML，后续全部基于 digest 操作
配合内容信任（DCT）验证发布者身份
digest 确保“内容没被改”，但不保证“是谁发的”。启用 Docker Content Trust 后：
- 设置 DOCKER_CONTENT_TRUST=1，所有
pull和push自动触发 Notary 签名检查 - registry 对 manifest 的 digest 进行数字签名，公钥由团队统一分发并预置
- 即使攻击者控制了 registry 权限，也无法伪造合法签名——没有私钥就签不了名，拉取时校验失败即拒收
落地建议：三步收紧 tag 风险
-
禁止生产环境使用裸 tag：K8s 清单、Ansible Playbook、部署脚本中，全部替换
image: nginx:1.21为image: nginx@sha256:7a... -
CI 输出必须包含 digest：构建成功后，用
docker images --digests或crane digest获取 digest，并存入制品库元数据或 Git Tag 注释 -
镜像仓库开启签名强制策略：如 Harbor 配置
signature.enabled: true，并对接内部 PKI，未签名镜像不允许推送至 prod 项目
