Docker

Docker Content Trust: Retirement and Migration Guidance

8.5内容质量

TL;DR · AI 摘要

Docker Content Trust（DCT）将于2026年7月正式退役，用户需迁移至现代替代方案如Sigstore/Cosign。

核心要点

  • Docker Content Trust（DCT）将于2026年7月15日完全退役。
  • DCT依赖的Notary v1项目已不再维护，现代替代方案包括Sigstore/Cosign和Notation。
  • DCT仅对已启用的用户产生影响，普通用户不受影响。

结构提纲

按章节快速跳转。

  1. §Docker Content Trust 退役概述

    Docker Content Trust（DCT）和Notary v1服务将于2026年7月正式退役。

  2. ·DCT 退役原因

    DCT依赖的Notary v1项目已不再维护，现代工具如Sigstore/Cosign已成为标准。

  3. ›受影响用户

    DCT仅对已启用的用户产生影响，普通用户不受影响。

  4. ·迁移路径

    Docker将分阶段退役DCT，包括写入和读取的停用时间表。

  5. ›替代方案

    现代替代方案包括Sigstore/Cosign和Notation，它们支持OCI原生签名。

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）
  • Docker Content Trust 退役
    • 退役原因
      • Notary v1项目不再维护
      • 现代工具如Sigstore/Cosign成为标准
    • 迁移路径
      • 分阶段退役
      • 替代方案：Sigstore/Cosign、Notation

金句 / Highlights

值得收藏与分享的关键句。

#Docker#容器安全#Notary#Sigstore#Cosign
打开原文

Docker 内容信任：停用与迁移指南 | Docker

Docker 内容信任：停用与迁移指南

发布于 2026 年 6 月 16 日

Julia Wilson

和

Aditya Tripathi

TLDR：Docker 内容信任（DCT）以及 notary.docker.io 上的 Notary v1 服务将被完全停用（首次于 2025 年 7 月宣布）。这篇博客解释了将发生的变化、受影响的用户以及如何迁移到现代的替代方案。

十年前，Docker 内容信任（DCT）为容器生态系统提供了第一个验证镜像完整性和发布者的方法，其基础是 The Update Framework 和 Notary v1 项目。上游的 Notary v1 代码库已不再维护，更现代的签名工具已成为标准，如今，只有极少数（少于 0.05%）的 Docker Hub 拉取操作依赖于 DCT。

去年我们开始为 Docker 官方镜像停用 DCT，现在我们正在完成这项工作，通过完全停用 DCT 以及 notary.docker.io 上的 Notary v1 服务。本文将介绍将发生的变化、受影响的用户（对大多数人来说，没有影响）以及用户可以使用的现代替代方案。

为什么我们要停用 Docker 内容信任（DCT）？

DCT 依赖于上游的 Notary v1 服务器，这是基于 TUF 的原始实现，于 2015 年首次发布，该项目已不再维护。近年来，生态系统已标准化为 OCI 原生的签名工具，如 Sigstore/Cosign 和 Notary 项目的 Notation，这些工具将签名与镜像一起存储在任何符合规范的注册表中，无需运行独立的信任基础设施。更广泛的生态系统已开始弃用这种方法——微软多年前已弃用 Azure 容器注册表中的 DCT 支持，Harbor 也弃用了 Notary v1 支持。

停用 Notary v1 让我们能够将投资转向其他现代、基于标准的工具（如下所述），这些工具开发者已经在采用，同时推动 Docker Hub 上的安全默认值成为一等公民。

这个变化会影响谁？

DCT 是可选的，普通的镜像拉取（docker pull）不会使用 Notary 服务，因此如果你从未有意启用它，你的工作流程不会有任何变化。你可以在此处停止阅读。

如果你配置了 DCT 用于使用，这个变化对你才会有影响，通常表现为以下几种方式之一：

  • 你在环境、shell 配置文件、CI 管道或 Dockerfile 中设置了 DOCKER_CONTENT_TRUST=1。
  • 你的脚本或自动化使用了 docker trust sign、docker trust inspect 或 docker trust revoke。
  • 你的 Kubernetes 准入控制器或部署策略检查 DCT 签名。
  • 你使用 DCT 签名功能将镜像发布到 Docker Hub。

如果你从未设置过 DOCKER_CONTENT_TRUST 并且不使用 docker trust 命令，这个变化不会影响你。

停用路径：时间表

我们将分阶段逐步停用 DCT，而不是一次性全部停用。这些停用是短暂的、计划中的停机时间，它们是演练，用于找出仍依赖该服务的任何管道，同时还有时间修复它们。写入操作在读取操作之前失效，因此签名功能在验证之前就会失效，发布者可以尽早得到通知。

日期

发生的事情

2026 年 7 月 14 日

4 小时写入停用

2026 年 7 月 15 日

2026 年 8 月 10 日

4 小时读取停用

2026 年 8 月 12 日

2026 年 12 月 8 日

全面关闭

Windows 系统运行约 4 小时，从太平洋时间上午 8 点开始。

请注意，这仅影响 DCT 信任操作；普通的 docker pull 和 docker push 操作将在这些时间段内继续正常运行。

如果您受到影响应如何处理：迁移指南和替代方案

如果上述任何情况描述了您的设置，以下是如何干净地迁离 DCT 的方法。生态系统已经确定了一些强大且广泛采用的工具，因此这更像是一份菜单，而不是一份手册。这些步骤从最快解除阻塞到最完整的设置不等；选择最适合您工作流程的领先技术，并根据您的具体情况尽可能深入列表。

确保镜像拉取成功

如果您唯一的目标是确保镜像拉取在关闭日期后继续正常工作，请禁用 DCT。这是解除工作流程阻塞的最快方法，但会移除标签级别的验证。

code
# 从当前的 shell 会话中移除
unset DOCKER_CONTENT_TRUST

# 或者显式禁用它
export DOCKER_CONTENT_TRUST=0

搜索您的环境中可能设置此变量的任何地方，包括 shell 配置文件、CI/CD 配置、Compose 文件和 K8s 清单。一旦禁用 DCT，所有拉取操作将继续正常进行。

确保拉取操作可重复

当镜像更新时，镜像仓库中的标签可能会更改。通过 digest 拉取镜像可以确保您获得预期的精确镜像内容，无论标签是否被移动或覆盖。digest 是不可变的。

code
# 查找您已拉取镜像的 digest
docker pull busybox:latest
docker images --digests busybox
# REPOSITORY   TAG       DIGEST                                                                    IMAGE ID
# busybox      latest    sha256:f85340bf...   abc123def456

# 通过 digest 拉取
docker pull busybox@sha256:f85340bf...

在 Dockerfile 中使用 digest 以实现可重复的构建，并在 Kubernetes 清单或 Compose 文件中使用以确保可预测的部署。

digest 锁定验证内容完整性（您获得的正是您所要求的），但它本身并不能证明发布者身份。为此，您需要加密签名，这就是 Sigstore/Cosign 和 Notation 的作用所在。

证明发布者身份

在 Hub 中，有两个成熟且积极维护的签名项目已取代了 DCT 的签名功能。两者都在符合 OCI 的镜像仓库中与镜像一起存储签名。

#### 选项 A：Sigstore / Cosign

Cosign 是 Sigstore 项目的一部分，支持基于身份的签名，使用与 OIDC 身份绑定的短期证书。它将签名作为 OCI 工件存储在同一个仓库中，与镜像一起。

  • Sigstore 快速入门：https://docs.sigstore.dev/quickstart/quickstart-cosign/
  • GitHub 上的 Cosign：https://github.com/sigstore/cosign

#### 选项 B：Notation

Notation 是 Notary 项目的 CLI。它使用基于证书的 PKI 模型，并将签名作为 OCI 引用工件存储。

  • Notation 快速入门：https://notaryproject.dev/docs/quickstart/
  • GitHub 上的 Notation：https://github.com/notaryproject/notation

在生产环境中强制验证

对镜像进行签名只是故事的一半。为了获得完整的安全优势，您需要强制仅允许部署已签名的镜像。

Kyverno（与 Cosign 兼容）

Kyverno 可在将镜像拉取到集群之前验证 Cosign 签名。有关详细信息，请参阅文档。

Ratify + Gatekeeper（与 Notation 兼容）

Ratify 可在允许 pod 之前验证 Notation 签名。有关设置说明，请参阅 Ratify 快速入门。

使用 Docker 加固镜像作为内置替代方案

如果你目前依赖 DCT 来验证来自 Docker Hub 的基础镜像，那么切换到 Docker 加固镜像（DHI）是一条免费且安全的前进路径。每个 DHI 都内置了加密签名、来源证明和 SBOM。

这意味着你之前依赖 DCT 进行的完整性检查不仅得到了保证，还进一步增强了安全性。DHI 镜像在设计上是精简的，并且在出现新的 CVE 时会持续重建。你不仅仅是在更换一个验证机制，你从一开始就能获得一个更安全的基础镜像。

  • 了解更多请访问：https://docs.docker.com/dhi/
  • 或者查看免费的目录：dhi.io

需要帮助？

在你规划迁移时，有几点需要注意。

如果你目前是使用 DCT 对镜像进行签名的 Docker Hub 发布者，Docker 无法代表你提供替代的签名。你需要采用 Cosign 或 Notation 来对自己的镜像进行签名。

如果你使用的是由 DCT 签名的第三方镜像，请直接联系这些发布者，以确定他们是否计划采用现代的签名方式。

有关关闭相关的问题或需要帮助制定迁移计划，请联系 Docker 支持团队。

关于作者

用户体验研究员，Docker

高级首席产品市场经理，Docker

Aditya Tripathi 负责 Docker 安全产品组合的产品营销，专长包括安全默认设置、供应链风险以及为开发人员提供实用的安全功能。

产品

目录

相关文章

  • 2026 年 5 月 12 日 Docker AI 治理：安全地解锁代理自主性 介绍 Docker AI 治理：集中控制代理如何执行、它们在网络中可以访问哪些资源、可以使用哪些凭证以及可以调用哪些 MCP 工具，这样公司中的每个开发人员都可以在任何工作环境中安全地运行 AI 代理。你的笔记本电脑就是新的生产环境。代理是最大的生产力提升…… Srini Sekaran 立即阅读
  • 2026 年 6 月 15 日 Docker 加入 Athena 联盟：跨行业协作保障供应链安全 AI 正在降低供应链攻击的门槛。Docker 加入了 Athena 联盟，这是一个跨行业的努力，旨在协调对开源软件的防御，建立在我们为每个开发人员提供默认安全工具以及在生态系统中共享信号的记录之上。Tushar Jain 立即阅读
  • 2026 年 6 月 11 日 Docker 加固镜像与 Docker 和 Aikido 增强了漏洞扫描 Aikido 现在使用内置的 VEX 支持扫描 Docker 加固镜像（DHI）。Docker 验证为不可利用的漏洞会自动从队列中移除，因此开发人员可以专注于真正重要的发现。这篇文章将介绍发生了哪些变化、为什么这很重要以及用户如何从新的集成中受益。为什么团队…… Dan Stelzer 和 Bjorn Hovd 立即阅读
  • 2026 年 6 月 8 日 开发团队的 5 个软件供应链安全最佳实践 了解容器化交付的关键软件供应链安全最佳实践，从可信的基础镜像和依赖管理到构建来源和运行时监控。Aditya Tripathi 立即阅读