docker内容信任（dct）需显式启用并协同密钥管理、仓库支持与签名操作：先设docker_content_trust=1启用客户端校验，再确保docker hub默认支持、acr需手动开启（2028年3月31日弃用）、harbor需启用content_trust并对接cosign或notary v2，私有registry则须部署notary或改用cosign；首次推送会自动生成根密钥和targets密钥，签名绑定于确定tag（非latest），失败常见原因包括未签名、时间偏差超5分钟、证书链不可信或权限不足。
Docker 镜像内容信任（Content Trust，DCT）不是开箱即用的功能，必须显式启用并配合密钥管理、仓库支持和签名操作才能生效。核心目标是确保拉取的镜像确实来自可信发布者且未被篡改——它验证的是镜像标签对应的 manifest digest，而不是镜像文件本身。
启用客户端信任检查
这是最基础、最关键的一步：
- 临时启用：
export DOCKER_CONTENT_TRUST=1 - 永久启用：把这行加到
~/.bashrc或~/.zshrc，然后source生效
⚠️ 不设这个变量，docker pull和docker build --push完全不校验签名，哪怕镜像已签名也视而不见
确认目标仓库支持签名验证
不同仓库支持方式不同，不能一概而论：
- Docker Hub：默认支持，无需额外配置
- Azure Container Registry（ACR）：需在 Azure 门户中手动开启「内容信任」策略（注意：2026年5月31日后新注册表已无法启用，2028年3月31日将彻底弃用）
-
Harbor：必须启用
content_trust功能，并后端对接 Notary v2 或 Cosign（推荐 Cosign，Notary v1 已弃用） - 私有 Registry（如 registry:2）：原生不支持；必须部署 Notary Server + Signer，或改用支持 OCI Artifact 的签名服务（如 Cosign + OCI registry）
生成与管理本地密钥
首次启用 DCT 时会自动生成根密钥（root key），但需注意：
- 根密钥保存在
~/.docker/trust/private/，务必离线备份，丢失则无法验证已有签名 - 每个仓库（如
myorg/app）会单独生成 targets 密钥（发行密钥），用于签署该仓库下的具体 tag - 若需指定密钥或跨环境复用，可用
docker trust key generate <name></name>手动创建，再通过docker trust signer add绑定到仓库
推送带签名的镜像
签名绑定在明确 tag 上（不能是 latest 这类易变标签）：
- 构建并打标：
docker build -t myreg/myapp:v1.2.0 . - 登录仓库：
docker login myreg - 推送（自动触发签名）：
docker push myreg/myapp:v1.2.0
✅ 此时 Docker 会：检查 targets 密钥 → 若无则生成 → 用 root key 签署 targets key → 再用 targets key 签署该 tag 对应的 manifest digest
常见失败原因与应对
-
no trust data available：目标 tag 从未被签名，检查是否推送成功、tag 是否拼写一致 -
signature verification failed：本地时间偏差超过 5 分钟、中间代理篡改响应、或证书链不可信（私有 Notary 需把 CA 证书放入/etc/docker/certs.d/<host>:<port>/ca.crt</port></host>） -
permission denied：使用了仅具仓库范围权限的 token（ACR 明确限制此类 token 不支持 DCT）
不复杂但容易忽略
