Docker内容信任（DCT）通过签名机制建立从构建到运行的镜像信任链，以标签为单位签名，需启用DOCKER_CONTENT_TRUST、管理密钥生命周期并配合运行时验证策略确保安全，但将于2028年3月31日弃用，建议迁移到Notary v2或cosign。
通过Docker镜像签名（Content Trust，DCT）确保分发内容安全，核心是让每个镜像在推送和拉取时都绑定可验证的发布者身份与不可篡改的内容摘要。它不是加一层“锁”，而是建立一条从构建到运行的信任链——只要任一环节拒绝未签名或签名失效的镜像，攻击者就无法混入恶意版本。
启用DCT并强制签名流程
DCT是Docker原生支持的信任机制，依赖Notary服务管理签名元数据。启用后，所有docker push和docker pull操作自动参与签名或校验：
- Linux/macOS下执行export DOCKER_CONTENT_TRUST=1；Windows PowerShell中运行$env:DOCKER_CONTENT_TRUST=1
- 首次推送时自动生成根密钥和仓库级签名密钥，私钥默认存于~/.docker/trust/private，必须离线备份、严禁共享
- 推送命令如docker push myregistry.azurecr.io/app:v1.2会触发自动签名，客户端提示输入密码短语保护私钥
区分标签粒度，按需控制信任边界
DCT以标签（tag）为单位签名，同一仓库可混合存在已签名与未签名镜像，适合多环境协同：
- 只对:stable、:prod等关键标签签名，开发用的:dev或:latest（若不固定）可不签
- 注册表（如Azure Container Registry）支持DCT，但注意：2026年5月31日起新注册表将无法启用DCT；2028年3月31日DCT将被完全弃用，建议同步规划向Notary v2或cosign迁移
- 避免使用带存储库范围权限的令牌进行DCT推送/拉取，这类令牌当前不支持签名操作
在消费端严格执行验证策略
签名本身无防护力，真正起作用的是运行时拒绝未验证镜像：
- Kubernetes中通过ImagePolicyWebhook或OPA/Gatekeeper拦截未签名、签名过期或公钥不匹配的镜像拉取请求
- CI/CD流水线中，在docker pull前调用notary list
检查有效签名；失败则中止部署 - Docker daemon 20.10+ 支持--signature-verification启动参数，配合本地trust store实现运行时强校验
密钥生命周期管理不能省略
长期复用密钥等于给攻击者留后门：
- 为dev/staging/prod环境分配独立签名密钥，禁止跨环境混用
- 设定密钥有效期（例如90天），到期前自动轮换，并同步更新集群信任列表
- 接入日志系统采集cosign verify或notary verify失败事件，对“证书不可信”“哈希不匹配”“签名时间戳过期”等立即告警
