docker content trust（dct）需嵌入构建、推送、拉取、部署、运行五环节并强制验证签名，非单纯启用即安全；其信任链依赖密钥管控与策略前置，且将于2028年3月31日完全弃用，建议迁移至cosign+notary v2。

启用 Docker Content Trust（DCT）本身不等于安全，真正起作用的是把签名验证嵌入构建、推送、拉取、部署、运行五个环节，并让每个环节都拒绝未签名或签名失效的镜像。它不是加一道锁，而是建立一条不可绕过的信任链。

构建与推送阶段：签名即准入

必须设置 DOCKER_CONTENT_TRUST=1，否则所有签名操作都不会触发。首次推送时自动生成根密钥和 targets 密钥，私钥默认存于 ~/.docker/trust/private/，务必离线备份、严禁共享。

• 推送命令如 docker push myreg.io/app:v1.2 会自动签名该标签对应的 manifest 摘要
• 禁止对 :latest 这类动态 tag 签名——签名绑定的是固定摘要，latest 指向可能随时变更，导致验证失效
• 生产环境禁用本地自动生成密钥，应接入企业 PKI 或 Fulcio OIDC 签发短期证书，绑定 CI 身份（如 GitHub Actions 工作流）
• 推送前同步附加 SBOM（CycloneDX）和 SLSA Provenance 声明，使用 oras attach 存入同一仓库路径，满足“交付物可追溯”监管要求

拉取与部署阶段：拒绝未验证即生效

客户端启用 DCT 后，docker pull 不再只是下载，而是自动校验签名有效性、时间戳、密钥 ID 及证书链完整性。任一失败即退出并返回 exit code 1。

Learn Docker

通过 LabEx 容器基础课程和镜像/编排实验学习 Docker。Docker 课程和实验通过 LabEx MCP 获取，返回 labex.io 链接以继续。

下载

• Kubernetes 中必须集成 ImagePolicyWebhook 或 cosign-webhook admission controller，在 Pod 创建前拦截未签名/签名过期/公钥不匹配的镜像
• CI 流水线中，docker pull 后立即执行 notary list <repo></repo> 或 cosign verify，失败则终止部署，不可跳过
• 避免依赖 docker run --signature-verification 这类运行时开关——它依赖 dockerd 版本且易被绕过；策略必须前置到调度层

密钥与策略管理：建立可持续的信任锚点

DCT 基于 TUF（The Update Framework），其安全性最终取决于密钥生命周期是否可控。长期复用密钥等于为攻击者留后门。

• 为 dev/staging/prod 分配独立 targets 密钥，禁止跨环境复用
• 设定密钥有效期（如 90 天），到期前自动轮换，并同步更新集群信任列表
• 根密钥必须离线保管，推荐使用 HSM 或云 KMS（如 Azure Key Vault）托管，禁止硬编码在 CI 脚本中
• 接入日志系统采集 cosign verify 或 notary verify 失败事件，对“证书不可信”“哈希不匹配”“时间戳过期”等立即告警

注意弃用时间线与迁移路径

Docker Content Trust 已进入退役倒计时：

• 2026 年 5 月 31 日起，新注册的私有 registry 将无法启用 DCT
• 2028 年 3 月 31 日，DCT 将被完全弃用
• 建议现在就启动向 Cosign + Notary v2 迁移：支持 OCI Artifact 签名、Sigstore 生态、OIDC 身份绑定与 Rekor 透明日志，更轻量、更开放、更适配现代 CI/CD