如何配置 Docker 内容信任 Content Trust 来保证镜像安全？

在容器化部署中，镜像来源是否可信直接决定了整个系统的安全边界。Docker 内容信任（Docker Content Trust，简称 DCT）是一套基于 The Update Framework（TUF）规范的签名与验证机制，它让镜像的发布者和消费者之间建立密码学层面的信任链。当 DCT 开启时，Docker 客户端在拉取或运行镜像前会自动校验镜像标签的数字签名，只有持有合法私钥签名的镜像才能被使用，从而阻断被篡改或伪造的镜像进入生产环境。

Docker 内容信任的核心原理与信任模型

DCT 的底层依赖 Notary 服务与 TUF 规范。TUF 将信任角色分为根密钥（root）、目标密钥（targets）、快照密钥（snapshot）和时间戳密钥（timestamp），其中根密钥是信任锚，目标密钥用于给具体的镜像标签签名。当你对某个镜像仓库启用内容信任后，Docker 客户端会把镜像的哈希值和签名推送到 Notary 服务器，拉取时再从 Notary 获取签名元数据并与本地计算的镜像摘要比对。

这种模型的好处在于即使某个签名密钥泄露，也可以通过根密钥进行密钥轮换而不影响整体信任。同时 TUF 设计了过期时间和阈值签名，避免单点密钥丢失造成全网瘫痪。对于普通开发者而言，最直观的感受是：没有签名的镜像即使存在于镜像仓库中，使用 docker run 也会直接报错，而不是悄悄运行。

需要注意的是，DCT 默认只保护通过 docker push 和 docker pull 显式操作的标签，且必须通过环境变量 DOCKER_CONTENT_TRUST=1 开启。它并不替代镜像扫描或漏洞检测，而是解决“这个镜像是否来自你信任的人且未被修改”这一问题。在多人协作或外部基础镜像引用的场景下，明确信任边界比单纯依赖网络隔离更可靠。

本地与服务器端 Content Trust 的基础配置步骤

要在本地开启 DCT，最简单的方式是设置环境变量。执行 export DOCKER_CONTENT_TRUST=1 后，后续所有 push 和 pull 操作都会强制签名验证。第一次对某个镜像仓库签名时，Docker 会在本地 ~/.docker/trust 目录生成根密钥和仓库密钥，并提示设置两道密码：根密钥密码用于保护最高信任锚，仓库密钥密码用于日常签名。这两个密钥务必离线备份，因为丢失后将无法再为该仓库签署新版本。

如果团队需要集中管理签名，应当部署独立的 Notary 服务。可以使用官方 notary 镜像快速启动：

# 启动 Notary 服务端（示例，生产需配置数据库与 TLS）
docker run -d --name notary-server 
  -e NOTARY_SERVER_STORAGE_TYPE=memory 
  -p 4443:4443 
  notary:latest server -standalone

# 配置 Docker 客户端指向私有 Notary
export DOCKER_CONTENT_TRUST_SERVER=https://192.168.0.1:4443
export DOCKER_CONTENT_TRUST=1

上述配置中，DOCKER_CONTENT_TRUST_SERVER 告诉客户端去哪里获取和提交签名元数据。生产环境必须将 Notary 的存储改为外部数据库，并启用 HTTPS，否则信任链本身会成为薄弱环节。此外，企业常结合 LDAP 或 OIDC 做人员审计，确保每次签名操作可追溯到具体责任人。

对于已经存在但未签名的旧镜像，直接开启 DCT 会导致拉取失败。此时需要先用信任密钥对存量镜像做一次性签名：docker trust sign repo.ippipp.com/old-image:1.0，或在暂未开启强制验证的过渡期逐步迁移。建议在 CI 脚本里加入判断逻辑，未签名就阻断发布，从流程上杜绝漏签。

使用 docker trust 命令进行镜像签名与自动化集成

Docker 提供了 docker trust 子命令来管理签名者、密钥和签名。添加签名者使用 docker trust signer add，例如将同事的证书加入仓库信任列表；签名镜像则使用 docker trust sign。下面是一段典型的手动签名流程：

# 登录镜像仓库
docker login ipipp.com

# 对镜像打标签并签名推送
docker tag myapp:local ipipp.com/myteam/myapp:1.2
docker trust sign ipipp.com/myteam/myapp:1.2

# 查看签名信息
docker trust inspect --pretty ipipp.com/myteam/myapp:1.2

在持续集成中，可以把根密钥和仓库密钥的加密文件存入密钥管理系统，流水线运行时解密到临时目录并设好环境变量，实现无人值守签名。但要注意，CI 机器若被攻破且持有签名密钥，攻击者可签署恶意镜像，因此推荐采用“构建机无签名权、发布机隔离签名”的分段模式，或使用硬件安全模块（HSM）保护私钥。

当不再信任某个签名者或密钥疑似泄露时，使用 docker trust signer remove 撤销其签名权，并通过 Notary 的密钥轮换功能发布新的根密钥。客户端在下一次拉取时会自动获取最新信任元数据，拒绝旧密钥签署的镜像。这种吊销机制让 DCT 不仅能防外部伪造，也能在内部事故中快速止损。

从实践看，DCT 的配置成本主要集中在密钥管理与流程改造，而非技术本身。只要把环境变量、Notary 地址和签名步骤固化到基础镜像构建规范和发布流水线中，就能以较低维护代价获得明显的供应链安全提升。对于监管严格的金融、医疗场景，镜像签名验签往往还是合规审计的硬性要求，提前落地 DCT 可以避免后续返工。

Docker_Content_Trust镜像签名notary修改时间：2026-08-14 20:06:34