Docker Content Trust（DCT）是防范镜像劫持与替换最直接有效的手段，通过GPG签名强制验证镜像在构建、推送、拉取全链路的完整性与来源可信性；启用DOCKER_CONTENT_TRUST=1后，所有docker pull和push操作自动校验签名，未签名或签名无效则拒绝执行，且首次拉取时缓存根公钥建立信任锚点，配合Notary服务、时间戳密钥及CI/CD门禁实现端到端安全防护。
启用Docker Content Trust（DCT）是防范镜像劫持与替换最直接有效的手段。它不依赖人工判断镜像来源是否“看起来可信”，而是通过密码学签名强制验证镜像在构建、推送、拉取全链路中是否被篡改或冒用——只要签名无效或缺失，Docker就拒绝执行操作。
强制启用内容信任并理解其拦截逻辑
DCT不是可选功能，而是一种运行时策略。设置环境变量后，所有docker pull和docker push操作都会自动触发验证：
-
export DOCKER_CONTENT_TRUST=1—— 启用后，docker pull nginx:latest只接受由nginx官方密钥签名的镜像；若镜像未签名，或签名来自伪造仓库，命令直接失败，不会静默下载 - 该机制对中间人攻击特别有效：即使攻击者劫持了DNS或代理了registry流量，也无法伪造合法签名，因为私钥始终保留在发布者本地
- 注意：
DOCKER_CONTENT_TRUST=1仅影响远程操作，不影响docker build或本地docker run已存在的镜像
使用可信根密钥建立发布者身份锚点
信任不是凭空产生的，而是从首次拉取时缓存的根公钥开始建立：
- 第一次拉取某仓库（如
docker.io/library/alpine）的已签名镜像时，Docker会下载并本地存储其根证书（root public key），后续所有该仓库的标签签名都基于此根密钥逐层验证 - 若攻击者试图用另一个私钥为同名镜像（如
alpine:3.19）签名并上传到镜像代理或私有仓库，客户端因无法用已知根公钥验证其签名，会直接报错no trust data for alpine:3.19 - 企业可自建Notary服务并预置内部根公钥，确保开发机只信任公司签名的镜像，彻底隔离外部不可控源
配合镜像标签签名与时间戳防止重放与过期利用
DCT不仅验“是谁签的”，还验“什么时候签的”和“签的是不是最新版”：
- 每个镜像标签（如
dvwa:2.1）由独立的目标密钥（targets key）签名，避免一个密钥泄露导致全部标签失效 - 时间戳密钥（timestamp key）每天自动更新一次，保证客户端拉取时能确认该标签签名在有效期内；攻击者即使截获旧镜像层，也无法用过期签名欺骗新客户端
- 签名数据（包括manifest digest和元数据）与镜像本体分离存储于Notary服务器，即使registry被入侵，只要Notary未沦陷，签名验证仍可靠
在CI/CD中嵌入签名验证作为部署门禁
把DCT验证变成自动化流程中的硬性卡点，比依赖人工检查更可靠：
- 在Kubernetes集群的镜像拉取策略中配置
imagePullPolicy: Always并确保节点已启用DCT，让kubelet在启动Pod前自动校验签名 - CI流水线中，在
docker push前插入docker trust sign步骤；在部署阶段执行docker pull并捕获退出码——非零即失败，立即中止发布 - 搭配私有registry使用时，需为registry配置TLS并启用DCT支持（如Docker Registry v2.8+），否则
localhost:5000等HTTP地址默认被DCT拒绝
