必须强制签名验证作为镜像拉取前置门槛：全局启用DOCKER_CONTENT_TRUST=1，绑定可信发布者身份（如Cosign限定OIDC签发者），禁用不可信镜像加速器，显式声明带哈希的固定标签，守护进程级启用--signature-verification，并通过Admission Controller运行时拦截未签名镜像。
要杜绝假冒伪劣镜像在宿主机上被拉起，核心不是“检测后再拦截”，而是让非法镜像根本无法通过准入关——签名验证必须成为拉取前的强制门槛，而非可选检查。
在宿主机层面强制启用签名验证
最直接有效的方式是通过环境变量全局启用 Docker 内容信任（DCT），使所有 docker pull 和 docker run 操作自动拒绝未签名镜像：
- 执行
export DOCKER_CONTENT_TRUST=1（临时生效）或写入~/.bashrc//etc/environment（长期生效） - 首次拉取时会初始化本地信任数据库，自动信任 Docker Hub 官方根密钥；对私有仓库需提前导入可信根证书
- 一旦启用，遇到未签名镜像（如
docker.io/library/nginx:alpine若未被官方签名）会立即报错：no trust data for ...
绑定可信发布者身份，防止“假签名”
仅验证签名存在还不够——攻击者可能用自签密钥伪造签名。必须限制“谁的签名才被接受”：
- 使用 Cosign 时，在验证阶段指定 OIDC 签发者和身份正则表达式，例如只信任 GitHub Actions 在
main分支构建的镜像：cosign verify --certificate-oidc-issuer https://token.actions.githubusercontent.com \<br> --certificate-identity-regexp "https://github.com/myorg/.*/.github/workflows/.*@refs/heads/main" \<br> registry.example.com/app:v1.2.0
- 对 DCT，可通过
notaryCLI 手动管理信任根，并将 Targets 密钥与 CI 系统绑定，禁止人工推送 - 生产环境避免使用本地生成密钥，改用云 KMS 或 Fulcio 自动签发短时效证书，降低密钥泄露风险
从源头堵住签名绕过路径
很多“假冒镜像”并非绕过验证，而是利用配置漏洞跳过验证：
- 禁用所有非必要镜像加速器，检查
/etc/docker/daemon.json中的registry-mirrors，移除不可信代理（如社区维护的公共镜像站） - 不依赖
docker build --pull自动拉取基础镜像，而是在 Dockerfile 中显式声明已签名的 base 镜像（如FROM registry.example.com/base:ubuntu22.04@sha256:...） - 禁止使用
:latest这类浮动标签——DCT/Cosign 对标签签名后禁止覆盖，但:latest易被恶意重推，应强制使用带 commit hash 的固定标签
运行时再加一道防线
即使宿主机配置了 DCT，仍需防范配置被临时关闭或容器引擎绕过：
- 在
dockerd启动参数中加入--signature-verification（需 dockerd ≥ 20.10），使守护进程级强制校验 - 部署
cosign-webhook或KyvernoAdmission Controller，当 Pod 创建请求到达 kube-apiserver 时实时验证镜像签名，未通过则拒绝调度 - 定期审计日志，监控
cosign verify或notary list的失败事件，对“证书过期”“哈希不匹配”“签发者不匹配”等告警及时响应
