Docker Content Trust（DCT）需嵌入构建、推送、拉取、部署、运行五环节并强制验证签名，非单纯启用即安全；其信任链依赖密钥管控与策略前置，且将于2028年3月31日完全弃用，建议迁移至Cosign+Notary v2。
启用 Docker Content Trust（DCT）本身不等于安全，真正起作用的是把签名验证嵌入构建、推送、拉取、部署、运行五个环节，并让每个环节都拒绝未签名或签名失效的镜像。它不是加一道锁，而是建立一条不可绕过的信任链。
构建与推送阶段：签名即准入
必须设置 DOCKER_CONTENT_TRUST=1，否则所有签名操作都不会触发。首次推送时自动生成根密钥和 targets 密钥，私钥默认存于 ~/.docker/trust/private/，务必离线备份、严禁共享。
- 推送命令如
docker push myreg.io/app:v1.2会自动签名该标签对应的 manifest 摘要 - 禁止对
:latest这类动态 tag 签名——签名绑定的是固定摘要，latest指向可能随时变更，导致验证失效 - 生产环境禁用本地自动生成密钥，应接入企业 PKI 或 Fulcio OIDC 签发短期证书，绑定 CI 身份（如 GitHub Actions 工作流）
- 推送前同步附加 SBOM（CycloneDX）和 SLSA Provenance 声明，使用
oras attach存入同一仓库路径，满足“交付物可追溯”监管要求
拉取与部署阶段：拒绝未验证即生效
客户端启用 DCT 后，docker pull 不再只是下载，而是自动校验签名有效性、时间戳、密钥 ID 及证书链完整性。任一失败即退出并返回 exit code 1。
- Kubernetes 中必须集成
ImagePolicyWebhook或cosign-webhookadmission controller，在 Pod 创建前拦截未签名/签名过期/公钥不匹配的镜像 - CI 流水线中，
docker pull后立即执行notary list <repo>或cosign verify，失败则终止部署，不可跳过 - 避免依赖
docker run --signature-verification这类运行时开关——它依赖 dockerd 版本且易被绕过；策略必须前置到调度层
密钥与策略管理：建立可持续的信任锚点
DCT 基于 TUF（The Update Framework），其安全性最终取决于密钥生命周期是否可控。长期复用密钥等于为攻击者留后门。
- 为 dev/staging/prod 分配独立 targets 密钥，禁止跨环境复用
- 设定密钥有效期（如 90 天），到期前自动轮换，并同步更新集群信任列表
- 根密钥必须离线保管，推荐使用 HSM 或云 KMS（如 Azure Key Vault）托管，禁止硬编码在 CI 脚本中
- 接入日志系统采集
cosign verify或notary verify失败事件，对“证书不可信”“哈希不匹配”“时间戳过期”等立即告警
注意弃用时间线与迁移路径
Docker Content Trust 已进入退役倒计时：
- 2026 年 5 月 31 日起，新注册的私有 registry 将无法启用 DCT
- 2028 年 3 月 31 日，DCT 将被完全弃用
- 建议现在就启动向 Cosign + Notary v2 迁移：支持 OCI Artifact 签名、Sigstore 生态、OIDC 身份绑定与 Rekor 透明日志，更轻量、更开放、更适配现代 CI/CD
