如何启用 Docker 内容信任 DCT？开启镜像签名验证的完整指南

容器镜像的安全性一直是生产环境中不可忽视的问题。镜像从仓库拉取到运行，中间可能经历网络传输、代理转发等多个环节，如果没有验证机制，攻击者完全有可能在传输过程中替换镜像内容，或者向仓库推送一个伪造的同名镜像。Docker 内容信任（Docker Content Trust，简称 DCT）就是针对这类威胁设计的机制，它利用数字签名技术对镜像发布者的身份和镜像内容的完整性进行验证，只有签名合法且未被篡改的镜像才能被拉取和运行。本文将从原理、启用方法、常见问题几个方面展开讲解。

DCT 的核心原理是什么

Docker Content Trust 的底层实现基于 The Update Framework（TUF）框架，具体由 Notary 服务承担签名与验证工作。当镜像发布者执行 docker push 时，客户端会对镜像摘要（digest）进行签名，签名时使用的私钥保存在本地，而对应的公钥和签名元数据则存储在 Notary 服务器中，Docker Hub 内置了这套服务。

整个信任体系涉及几种密钥角色。根密钥（root key）是信任链的起点，用于签 NAMES 中间角色，默认保存在本机 ~/.docker/trust/private 目录下；目标密钥（targets key）负责对具体的镜像 tag 签名；快照密钥和时间戳密钥由 Notary 服务端管理，用于保证元数据的时效性和防回滚攻击。理解这套分层设计有助于排查签名失败的问题。

验证发生在拉取阶段。启用 DCT 后，docker pull 会先向 Notary 服务查询该镜像的签名元数据，校验签名链是否完整、内容摘要是否与仓库中的镜像一致，任何一环校验失败都会拒绝下载。这样即使镜像仓库被攻破，攻击者没有发布者私钥也无法伪造出合法签名。

如何启用与使用 DCT

启用 DCT 最简单的方式是通过环境变量 DOCKER_CONTENT_TRUST，设置为 1 后当前会话中的所有 push 和 pull 操作都会强制走签名验证流程。

export DOCKER_CONTENT_TRUST=1
docker pull alpine:latest

如果只想对个别命令启用，可以在命令前临时指定环境变量，例如 DOCKER_CONTENT_TRUST=1 docker pull nginx，这样不会影响其他操作的默认行为，适合在测试阶段逐步推广。

首次以发布者身份推送签名镜像时，客户端会引导你创建根密钥，需要设置两次强密码，随后再为仓库设置一个仓库级密码。这些密码用于加密本地私钥文件，一定不要丢失，否则将无法再对该仓库发布新签名。

export DOCKER_CONTENT_TRUST=1
docker login registry.ippipp.com
docker build -t registry.ipipp.com/team/app:v1.0 .
docker push registry.ipipp.com/team/app:v1.0
# 首次推送会提示创建 root key 和 repository key，按提示设置密码即可

推送完成后，可以使用 docker trust inspect 命令查看镜像的签名详情，输出中会列出签名人、签名时间和使用的密钥角色，方便在 CI 流程中做进一步校验。

docker trust inspect registry.ipipp.com/team/app:v1.0 --pretty

常见问题与生产环境实践

启用 DCT 后最常见的报错是拉取未签名镜像失败，提示类似 no trust data available。这是因为官方 Docker Hub 上绝大多数镜像是未签名的，开启强制验证后会全部拒绝。解决办法是确认业务依赖的镜像是否都有签名，或者临时关闭环境变量再操作，但生产环境不建议关闭。

密钥管理是落地的关键。根密钥丢失意味着整个信任链需要重建，建议将密钥目录 ~/.docker/trust 做离线备份并限制访问权限。在 CI 环境中，更推荐使用硬件保护或密钥管理服务托管私钥，避免把私钥文件直接放在构建机上。若需要更换密钥，可以通过 docker trust key generate 生成新密钥并用 docker trust signer add 添加协作者签名。

# 生成新的签名密钥
docker trust key generate new-signer --dir ~/.docker/trust
# 为镜像仓库添加签名者
docker trust signer add --key new-signer.pub new-signer registry.ipipp.com/team/app

在企业环境中，通常还会结合策略工具实现全局强制。例如使用 UCP 的策略引擎可以按仓库粒度强制要求签名，或者通过公共网关审计所有拉取请求的签名状态。另外需要注意，DCT 只覆盖 push 和 pull，docker build 基于本地缓存镜像构建时不会触发验证，因此在流水线中应尽量从远端拉取基础镜像并开启验证，避免缓存被污染带来的隐患。

总体来说，DCT 是一个低成本高收益的安全加固手段，配置上只需一个环境变量，核心工作量在于密钥管理和镜像供应链的签名规范。只要团队建立了私钥保管与签名发布的标准流程，就能有效防止镜像被篡改和伪造，为容器化应用的安全运行打下坚实基础。

Docker内容信任DCT镜像签名修改时间：2026-09-13 16:44:37