本质是docker内容信任（dct）机制拦截未签名、签名过期或不匹配的镜像；需检查docker_content_trust是否为1，确认镜像是否被notary/tuf签名且标签有效，推荐改用带sha256哈希的精确基础镜像。
当 Docker 构建过程中 FROM 指令拉取基础镜像时出现“签名验证失败”（如 failed to verify signature 或 signature verification failed），本质是镜像内容信任（Notary / TUF）机制拦截了未签名、签名过期或签名不匹配的镜像。这不是网络或权限问题，而是安全策略生效的结果。
确认是否启用了内容信任（DCT）
Docker 默认不启用内容信任；只有显式设置环境变量或使用 --disable-content-trust=false 时才会校验签名。检查当前行为：
- 运行
echo $DOCKER_CONTENT_TRUST：若输出1，说明已启用 DCT - 查看构建命令是否含
--disable-content-trust=false（等效于启用） - 某些企业版 Docker Hub 或私有 Registry（如 Harbor）可能强制开启签名验证
临时绕过签名验证（仅限测试/开发环境）
若确认镜像来源可信且只需快速构建，可禁用内容信任：
- 构建时加参数：
docker build --disable-content-trust=true . - 或临时关闭全局开关：
export DOCKER_CONTENT_TRUST=0，再执行docker build - 注意：生产环境不建议长期禁用，会失去防篡改保护
正确修复签名问题（推荐方案）
根本解决需确保镜像被可信密钥签名并推送到支持 TUF 的 Registry：
- 用
notary工具为镜像签名：例如notary -s https://notary.example.com add delegation -p ./key.pem my-registry/library/alpine:3.19 - 推送前签名：
DOCKER_CONTENT_TRUST=1 docker push my-registry/library/alpine:3.19（会自动触发本地签名） - 确认 Registry 支持并配置了 Notary 服务（如 Docker Hub 开启了“Content Trust”设置）
- 若使用私有 Registry（如 Harbor），需启用“Notary”组件并在项目中开启“Content Trust”策略
检查镜像标签与签名是否匹配
常见误操作：拉取了未签名的 alpine:latest，但 FROM alpine:latest 在 DCT 启用时会失败，因为 latest 很少被签名。建议：
- 改用带哈希的精确镜像：
FROM alpine@sha256:abc123...（跳过标签签名验证，只校验内容哈希） - 优先选用明确签名的 tag，如
alpine:3.19.1（Docker Hub 对部分稳定版本提供签名） - 用
notary list my-registry/library/alpine查看哪些 tag 已签名
