Docker Content Trust通过GPG签名验证镜像来源与完整性，启用后默认仅拉取已签名镜像；需生成根密钥和仓库级发行密钥，配置DOCKER_CONTENT_TRUST=1后构建或推送时自动/手动签名，并配合Notary服务及离线密钥管理确保安全。
Docker 的 Content Trust（内容信任）机制通过 GPG 签名验证镜像来源与完整性，防止拉取被篡改或伪造的镜像。启用后，docker pull 和 docker run 默认只接受已签名镜像（除非显式禁用）。配置核心是生成并分发可信密钥、设置环境变量、签名镜像并推送。
生成并管理信任密钥对
Content Trust 使用两类 GPG 密钥：
-
根密钥（Root Key）：全局唯一，用于签署其他密钥，首次启用时自动生成，保存在
~/.docker/trust/private/下，务必离线备份； -
发行密钥（Repository Key / Targets Key）：每个命名空间（如
myorg/myapp）独立生成，用于签名该仓库的具体镜像标签。
首次使用时，执行任意带 DOCKER_CONTENT_TRUST=1 的命令（如 export DOCKER_CONTENT_TRUST=1 后运行 docker pull hello-world）会自动创建根密钥。若需为特定仓库签名，先确保已登录 Docker Hub 或私有 Registry：docker login
启用 Content Trust 并签名镜像
启用方式有两种：
- 临时启用：
DOCKER_CONTENT_TRUST=1 docker build -t myorg/myapp:1.0 .→ 构建后自动签名； - 全局启用：
export DOCKER_CONTENT_TRUST=1（写入~/.bashrc持久生效）。
构建完成后，推送前需手动签名（若未在构建时自动触发）：docker trust sign myorg/myapp:1.0
该命令会检查本地是否存在对应仓库的发行密钥，若无则生成，并用根密钥签名该发行密钥，再用发行密钥签署镜像摘要（即 1.0 标签指向的 manifest SHA256）。
验证签名与调试常见问题
拉取时自动校验签名，失败则报错 no valid trust data for …。可手动查看签名信息：docker trust inspect --pretty myorg/myapp
输出包含根密钥 ID、发行密钥 ID、已签名标签及签名时间。
常见问题：
-
“No such key” 错误：说明本地缺失发行密钥，需重新登录并运行
docker trust signer add --key <pub-key-file><repo></repo></pub-key-file>（适用于协作场景）； - 私有 Registry 不支持：需确认 Registry 启用了 Notary 服务（Docker 官方 Notary Server），普通 Harbor 或 Nexus 需额外配置集成；
-
CI/CD 中签名失败：确保 CI 环境中设置了
DOCKER_CONTENT_TRUST=1，且拥有对应仓库的发行密钥（可通过docker trust key load导入）。
生产环境最佳实践
Content Trust 不是银弹，需配合其他安全措施：
- 根密钥必须离线存储，禁止提交到代码仓库；
- 为不同环境（dev/staging/prod）使用独立命名空间或标签策略，避免共用发行密钥；
- 在 CI 流水线中强制签名：构建成功后立即执行
docker trust sign，失败则中断发布； - 定期轮换发行密钥（
docker trust key rotate -f myorg/myapp），尤其在密钥泄露风险发生后。
不复杂但容易忽略：签名只保护镜像 manifest 和 layer digest，不加密内容本身，也不替代镜像扫描或最小化基础镜像等纵深防御手段。
