仅设置docker_content_trust=1无法实现强制来源验证，它仅触发客户端校验且存在静默降级风险；真正强制生效须配合私有notary v2服务、可信密钥预分发、dockerd级--signature-verification=true参数及kubernetes imagepolicywebhook等多层拦截机制。

仅设置 DOCKER_CONTENT_TRUST=1 环境变量，无法实现“强制来源验证”——它只开启客户端签名行为和拉取时的本地校验逻辑，不阻止未签名镜像被拉取或运行。真正强制生效，必须配合服务端策略、可信密钥分发与运行时拦截机制。

环境变量只是起点，不是策略终点

启用 DOCKER_CONTENT_TRUST=1 后：

• 所有 docker push 会自动生成并上传 TUF 风格的签名元数据（targets、snapshot 等角色）
• 所有 docker pull 默认只接受已签名镜像，但该行为可被静默绕过：若无法连接 Notary 服务、遇到 TLS 错误或 targets 密钥缺失，旧版 daemon 或 CI 环境常降级为无签名拉取
• 它不校验签名者身份是否受信，也不检查证书是否由企业 CA 签发，更不阻止未签名镜像在 Kubernetes 中被调度

私有仓库必须部署 Notary v2 或兼容签名后端

Docker 官方 notary.docker.io 仅支持 Docker Hub；私有 registry（如 Harbor、Nexus、Artifactory）需集成 Notary v2 插件或 Cosign-compatible 签名服务：

OpenClaw Docker Setup

在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...

下载

• Harbor 用户需启用 Notary v2 并配置 signatureVerification: true 策略
• 自签名证书必须显式放入 /etc/docker/certs.d/<notary-host>:4443/ca.crt</notary-host>，Docker daemon 不读系统 CA 库
• 首次 docker push 生成的 targets 私钥默认存于 ~/.docker/trust/private/，该路径在 CI runner 或 Pod 中不可靠，需提前用 notary key import 注入预批准密钥环

运行时层必须启用守护进程级拦截

从 Docker Engine v27 起，签名验证已下沉至 dockerd 层，但需显式启用：

• 启动 dockerd 时添加 --signature-verification=true（要求 ≥ v20.10）
• 确保 /etc/docker/trust/config.json 存在且含 "defaultVerify": true
• 将可信根证书和 targets 公钥导入 /etc/docker/trust/，否则验证失败时返回 HTTP 403 并清空缓存层
• 验证日志统一写入 /var/log/docker-trust-audit.log，含 traceID，可用于审计溯源

生产环境必须叠加准入控制策略

单靠 Docker 客户端或 daemon 仍存在逃逸可能，需在更高层设防：

• 在 Kubernetes 中部署 ImagePolicyWebhook（如 OPA/Gatekeeper/Kyverno），拒绝未签名镜像创建 Pod
• 私有 registry 配置策略：对 prod/ 命名空间下所有拉取请求，校验请求头是否含有效 application/vnd.cncf.notary.signaturereferrer
• CI/CD 流水线中嵌入 cosign verify 或 notary trust inspect 作为 gate step，任一失败则阻断推送