拉取 docker 镜像时验证数字签名的核心是启用 docker content trust（dct）或 cosign：设 docker_content_trust=1 后 pull 强制校验签名，仅接受已签名镜像；cosign 则通过 cosign verify --key 检查 oidc 身份、fulcio 证书链及签名时间，失败即阻断。
拉取 Docker 镜像时验证数字签名，核心是确保镜像未被篡改、来源可信。这不依赖“自动弹窗提示”，而是通过显式启用信任机制和验证命令来完成。
启用 Docker Content Trust（DCT）基础验证
Docker 原生支持的签名验证方式，适合快速启用基础级保障：
- 设置环境变量开启：运行 export DOCKER_CONTENT_TRUST=1，之后所有
docker pull操作都会强制校验签名 - 仅能拉取已签名镜像：若镜像未被发布者签名（如多数公共仓库的普通镜像），拉取会直接失败，报错类似 "No valid trust data for ..."
- 信任锚来自本地密钥：首次拉取时自动生成根密钥（
~/.docker/trust/private），公钥默认信任 Docker Hub；私有仓库需手动导入发布者公钥
用 Cosign 进行细粒度签名验证
Cosign 是当前主流的 OCI 兼容签名工具，比 DCT 更灵活，支持自定义策略和透明日志审计：
- 拉取前单独验证：执行 cosign verify --key cosign.pub
（需提前配置 COSIGN_EXPERIMENTAL=1） - 验证内容包含签名时间、OIDC 身份（如 GitHub Actions 的邮箱）、Fulcio 证书链，可确认是否由预期团队/流水线签发
- 配合 Trust Policy 文件，可设定规则：例如只允许
ghcr.io/myorg/**下由@myorg.com签发的镜像，其他一律拒绝
跳过验证的风险与临时应对
某些场景下（如测试环境或调试）可能想绕过签名检查，但必须清楚后果：
- 使用 --disable-content-trust 参数可临时关闭 DCT 验证，例如：
docker pull --disable-content-trust nginx:alpine - 该操作放弃完整性校验，镜像层可能被中间代理替换或仓库被入侵污染，生产环境严禁使用
- 若遇到 "missing signature key" 错误，通常不是镜像本身问题，而是本地未配置对应公钥或 DCT 未启用，应检查
DOCKER_CONTENT_TRUST环境变量及密钥路径
验证结果怎么看才可靠
成功验证不只是“没报错”，关键看输出中是否明确包含可信要素：
- DCT 方式：终端显示 "Pull (trusted) image..."，且不出现 "No trust data" 提示
- Cosign 方式：输出中含 "Successfully verified" + "Subject:
" + "Issuer: https://fulcio.sigstore.dev" 等字段 - 任何提示 "signature not found" 或 "invalid signature" 都代表验证失败，此时不应继续部署该镜像
