必须启用docker_content_trust=1全局开关，结合docker trust inspect预检签名、预置根密钥、校准系统时间，并确保registry支持notary或cosign签名验证。
要在 Linux 自动化部署中确保只拉取已签名镜像，核心是让 Docker 客户端在每次 pull 时强制校验签名，且整个流程不依赖人工干预。这不能只靠“推的时候签”，而必须让“拉的时候拒”成为默认行为。
设置全局信任检查开关
自动化脚本或 CI/CD 环境中，必须启用 DOCKER_CONTENT_TRUST=1。这不是可选项，而是执行校验的前提：
- 临时生效（适合单次 job）：
DOCKER_CONTENT_TRUST=1 docker pull myorg/app:v1.2.0 - 持久生效（推荐用于部署节点）：将
export DOCKER_CONTENT_TRUST=1加入/etc/profile.d/docker-trust.sh或用户级~/.bashrc，确保所有 shell 会话默认启用 - 注意：该变量对
docker pull、docker run（隐式触发 pull）、docker build --pull均生效；但docker run image:tag若本地已有镜像，则跳过拉取和校验——所以生产环境应禁用本地缓存或统一从 registry 拉取
确保目标 Registry 支持签名验证
签名有效 ≠ 能被验证。客户端开启 DCT 后，仍需后端支持签名元数据存储与分发：
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- Docker Hub 默认支持，开箱即用
- 私有 Registry（如 Harbor）必须启用内容信任功能，并集成 Notary 或启用 Cosign 兼容的 OCI Artifact 模式；单纯开启 HTTPS 不代表支持 DCT
- 若使用自建 Notary 服务，需额外设置
DOCKER_CONTENT_TRUST_SERVER=https://notary.example.com:4443，并把对应 CA 证书放入/etc/docker/certs.d/notary.example.com:4443/ca.crt
在 CI/CD 和部署脚本中嵌入签名验证逻辑
仅靠环境变量还不够。自动化流程应主动确认签名状态，失败即中断：
- 拉取前检查签名是否存在：
docker trust inspect --quiet myorg/app:v1.2.0 || { echo "No valid signature for v1.2.0"; exit 1; } - 结合 Kubernetes 部署时，在
kubectl apply前加入校验步骤，避免 YAML 提交后才发现镜像不可信 - CI 流水线中，禁止使用
:latest这类模糊 tag —— DCT 要求签名绑定到明确的 manifest digest，而latest可能指向不同镜像，导致签名失效或无法复现
密钥与时间同步是静默失败的常见原因
很多自动化任务“看似成功却未校验”，往往卡在这两个细节：
- 根密钥缺失：首次启用 DCT 时，
docker pull会自动生成~/.docker/trust/private/root.json；但若脚本运行在干净容器或新用户下，该文件不存在，会导致“no trust data”错误。解决方案是预置离线生成的根密钥，或在初始化阶段运行一次DOCKER_CONTENT_TRUST=1 docker pull hello-world - 系统时间偏差：签名验证依赖时间戳，若节点时间误差超过 5 分钟，会直接报
signature verification failed。建议在部署节点上启用systemd-timesyncd或chrony并定期同步
