仅设置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，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，任一失败则阻断推送
