docker镜像可信性验证需从签名、内容、运行、网络四层交叉确认：启用docker_content_trust校验签名防篡改；用docker inspect获取repodigests比对远程manifest确保内容完整；通过docker run测试启动、端口响应及配置加载验证功能可用；检查config.json认证、curl registry接口确认仓库访问权限。
验证 Docker 镜像是否可信、完整、可用，不能只看 docker images 有没有显示，得从签名、内容、运行、网络四个层面交叉确认。不同场景侧重点不同：拉取公共镜像重签名与 digest，自建镜像重构建逻辑与服务响应，迁移镜像重数据一致性。
验证镜像数字签名（防篡改）
启用 Docker Content Trust 后，所有拉取操作自动校验签名：
- 设置环境变量：
export DOCKER_CONTENT_TRUST=1（临时）或写入~/.bashrc - 拉取时若提示
no trust data for xxx，说明该镜像未签名；若直接报错signature verification failed，说明签名无效或密钥不匹配 - 查看签名信息：
notary -s https://notary.docker.io list <repo></repo>（需安装 notary CLI） - 关键检查点：系统时间是否准确（签名证书有效期依赖本地时间）、根密钥是否被误删、镜像是否来自受信任的 registry
验证镜像内容完整性（防损坏）
基于 digest 的哈希比对是最可靠的底层验证方式：
- 拉取后获取 digest：
docker inspect --format='{{.RepoDigests}}' nginx:latest，输出类似[nginx@sha256:abc123...] - 对比源 registry 中该镜像 manifest 的 digest（可通过 curl 访问
v2/<repo>/manifests/<tag></tag></repo>获取） - 若本地 digest 为空或与远程不一致，说明镜像拉取不完整或被中间代理修改
- 也可用
docker image ls --digests快速列出所有本地镜像及其 digest
验证镜像可运行性（功能正确）
启动容器并观察实际行为，是最终的功能闭环验证：
- 简单启动测试：
docker run --rm -it nginx:alpine sh -c 'echo OK && nginx -v'，确认基础命令能执行 - 端口服务验证：如
docker run -d -p 8080:80 --name test-nginx nginx:latest，再curl -I http://localhost:8080检查 HTTP 响应头 - 挂载与配置验证：若镜像依赖外部配置或卷，需模拟真实路径测试，例如
-v $(pwd)/conf:/etc/nginx/conf.d后检查配置加载是否生效 - 注意：避免使用
--rm+-d组合（冲突），调试时优先用前台运行模式
验证镜像仓库访问与认证（权限通路）
尤其在私有 registry 或企业环境中，拉取失败常源于认证或网络策略问题：
- 确认
~/.docker/config.json中对应 registry 的auth字段存在且未过期 - 手动触发认证流程：
docker pull my-registry.example.com/app:1.0，观察是否返回unauthorized: authentication required（说明配置缺失）或no basic auth credentials（说明未 login） - 测试 registry 连通性：
curl -v https://my-registry.example.com/v2/，应返回 200 或 401；若超时或 404，需检查 DNS、代理、TLS 证书或仓库服务状态 - 国内用户常见问题：镜像源配置错误导致拉取缓慢或失败，可用
docker info | grep "Registry"查看当前默认 registry 和镜像加速器
