Docker 容器镜像被篡改，教你验证镜像完整性
Docker 容器镜像被篡改是真实存在的风险：攻击者可能替换官方镜像、植入后门或恶意代码，导致生产环境沦陷。
作为运维人员，每次拉取镜像前都应验证它的完整性。
本文从零开始，教你三种从易到难的验证方式，每个步骤都附命令和输出示例，可以直接复制执行。
先看镜像摘要：最直接的完整性凭证
Docker 对每个镜像层计算唯一哈希值，称为 摘要 (digest)。
镜像被篡改后 digest 必然变化，所以我们先拿当前镜像的 digest 作为基准。
操作： 查看已拉取镜像的 digest
docker images --digests | grep nginx示例输出（注意 DIGEST 列）：
nginx latest abc123... sha256:1f2e3d... 复制这个 sha256:... 字符串，它就是镜像的“身份证”。
如果镜像还没拉取，可以先从 Docker Hub 等源站获取官方 digest：在 Hub 页面找到“Digests”标签，或通过命令远程查询：
docker manifest inspect nginx:latest --verbose输出头部的 digest 就是官方版本。
拉取时指定 digest，从源头防篡改
不要只靠 tag（如 :latest）拉取——tag 可以被重新指向恶意镜像。
正确做法是在 pull 命令里直接带上 digest。
命令示例：
docker pull nginx@sha256:1f2e3d...拉取完成后，再次运行 docker images --digests 确认本地 digest 与你期望的一致。
如果不一致，说明仓库或网络中间环节被篡改，立即停止使用。
批量验证技巧： 如果你维护多个容器，可以在 docker-compose.yml 中用 image 字段直接指定 digest：
services:
web:
image: nginx@sha256:1f2e3d...这样每次启动都会基于固定 digest，避免 tag 漂移。
启用 Docker Content Trust，给镜像加把锁
Docker Content Trust 使用数字签名保证发布者身份和镜像内容。
开启后，客户端只拉取经过签名的镜像。
开启方法：
export DOCKER_CONTENT_TRUST=1将这个环境变量写入 ~/.bashrc 或 /etc/environment 可永久生效。
之后所有 docker pull 命令都会强制校验签名：
- 如果镜像未签名，返回错误
No trust data for...。 - 如果签名被篡改，同样拒绝拉取。
注意： 仅官方镜像（如 nginx, ubuntu）和部分组织（如 bitnami）使用 Content Trust；
大量第三方镜像未签名，开启后可能拉不下来。
生产环境中建议只对核心基础镜像开启，或单独维护自己的私有签名仓库。
避坑指南：三个最容易忽略的点
- 不要在测试环境拉镜像，再传到生产：传输过程中可能被篡改，应该在生产环境直接 pull 并验证 digest。
- digest 对本地层重组敏感：如果使用
docker build构建新镜像，digest 会变——此时不能直接用上游 digest 验证，需配合签名或自建仓库的 digest。 - 环境变量失效：DOCKER_CONTENT_TRUST 只在当前 shell 生效，重启或新终端需要重新设置。建议写入 shell 配置文件。
效果验证：确认每一步都防篡改
完成上述操作后，用一条命令验证整个过程：
docker image inspect nginx@sha256:1f2e3d... --format '{{.RepoDigests}}'输出应显示你指定的 digest。
如果之前开启了 Content Trust，可尝试拉取一个未签名的镜像：
export DOCKER_CONTENT_TRUST=1
docker pull some/unsigned-image
# 预期报错: No trust data for...收到此错误，说明 Content Trust 生效，从源头拦截了未签名的镜像。
如果你正在构建或维护 Docker 环境，建议把验证镜像完整性纳入日常巡检脚本。
遇到可疑镜像时，先对比 digest，再检查构建历史 (docker history)，从多层维度确保容器镜像不被篡改。
