docker content trust（dct）需全局启用 docker_content_trust=1 并贯穿构建、推送、拉取、部署全链路，禁用 :latest 标签，配合基础设施层（如 kubernetes webhook、harbor 签名策略、daemon 参数）强化校验，且须规划迁移到 cosign + notary v2。
要让 Docker Content Trust（DCT）真正起到“强制签名校验”作用，不能只靠设一个环境变量。它本质是一条贯穿构建、分发、拉取、部署的不可绕过验证链，缺一环就可能失效。
必须设置 DOCKER_CONTENT_TRUST=1
这是所有操作的前提开关。不设它，Docker 完全不检查签名——docker pull 会静默下载任何镜像，docker push 也不会生成签名元数据。
- Linux/macOS：运行
export DOCKER_CONTENT_TRUST=1（临时）或写入~/.bashrc/~/.zshrc（永久） - Windows PowerShell：运行
$env:DOCKER_CONTENT_TRUST=1 - 验证是否生效：执行
echo $DOCKER_CONTENT_TRUST，输出应为1
推送时必须绑定明确标签，且签名自动触发
只有设置了 DOCKER_CONTENT_TRUST=1 后执行 docker push，才会自动生成并上传 TUF 元数据（如 targets.json）。
- 标签必须固定：用
:v1.2.0、:prod这类明确 tag，禁用:latest—— 它指向的 manifest 摘要随时可变，签名失去意义 - 首次推送会生成根密钥和 targets 密钥，私钥默认存于
~/.docker/trust/private/，务必离线备份、严禁共享或上传到 Git - 推送命令示例：
docker push myreg.io/app:v1.2.0（此时已自动签名）
拉取端必须拒绝未签名镜像，不能依赖“默认行为”
启用 DCT 后，docker pull 不再只是下载，而是执行完整校验：签名有效性、时间戳、密钥 ID、证书链完整性。任一失败即退出，返回 exit code 1。
- 典型错误提示：
-
remote trust data does not exist→ 该 tag 根本没被签名 -
signature verification failed→ 签名存在但校验失败（常见原因：本地时间偏差 >5 分钟、中间代理篡改、证书不被信任）
-
- 注意：
docker run本身不直接受 DCT 控制，它依赖的是镜像拉取时是否已通过验证。如果镜像是在未启用 DCT 时拉下来的，后续仍能运行
生产环境需叠加多层拦截，避免单点失效
仅靠客户端校验存在静默降级风险（如 Notary 服务不可达时旧版 daemon 可能跳过验证），必须在基础设施层加固：
- 在 Kubernetes 中部署
ImagePolicyWebhook（如 OPA/Gatekeeper/Kyverno），Pod 创建前拦截未签名、签名过期或公钥不匹配的镜像 - 私有 registry（如 Harbor）启用签名策略，配置
signatureVerification: true，拒绝未签名镜像被拉取 - Docker daemon ≥20.10 启动时添加
--signature-verification=true参数，并确保/etc/docker/trust/下预置可信公钥和根证书 - CI/CD 流水线中，在
docker pull后立即执行notary list <repo>:<tag></tag></repo>或cosign verify，失败则终止部署，不可跳过
注意：DCT 已进入弃用周期，建议同步规划迁移
Docker 官方已明确：
- 2026年5月31日起，新注册的私有 registry 将无法启用 DCT
- 2028年3月31日，DCT 将被完全移除
当前推荐路径是迁移到 Cosign + Notary v2：支持 OCI Artifact、OIDC 身份绑定、Fulcio 短期证书、Rekor 透明日志，更适配现代 CI/CD 和零信任架构
