核心在于阻断凭证在传输和存储环节被截获：强制HTTPS并校验证书、启用mTLS双向认证、凭据不落盘而交由系统密钥环或临时token管理、禁用不安全的Docker守护进程通信方式。
防范中间人攻击窃取 Docker 凭证，核心在于阻断凭证在传输和存储环节被截获的路径。重点不是“配置 Docker Client”本身，而是确保它只通过可信通道通信、不落盘明文凭据，并启用双向身份验证。
强制使用 HTTPS 并校验服务端证书
Docker Client 默认信任远程 Registry 的 TLS 证书，若未严格校验，攻击者可伪造证书实施中间人攻击。必须确保：
- 私有 Registry 必须使用由可信 CA 签发的证书（或企业内网 CA 已导入宿主机信任库），禁用自签名证书直连
- 客户端执行 docker login 时，URL 必须以 https:// 开头（如
docker login https://registry.example.com），避免因协议降级导致凭证走 HTTP - 若使用自建 Registry，需将 CA 证书复制到 Docker 守护进程信任目录（如
/etc/docker/certs.d/registry.example.com/ca.crt），否则客户端会跳过证书校验
启用 TLS 双向认证（mTLS）
仅校验服务端证书不够——攻击者可劫持已认证会话。双向 TLS 要求客户端也提供证书，实现强身份绑定：
- 为 Docker 客户端生成专用客户端证书+私钥，并由 Registry 的 CA 签发
- 将客户端证书配置到 Docker CLI：把
cert.pem、key.pem、ca.crt放入~/.docker/certs.d/registry.example.com/ - Registry 侧（如 Harbor 或自建 registry:2）需开启
tls.clientauth并配置信任该 CA - 此时 docker login 不再依赖用户名密码，而是基于证书完成身份认证，凭证不再在网络中传输
避免凭据明文落盘，改用凭证辅助工具
即使通信加密，~/.docker/config.json 中 Base64 编码的 auth 字段仍可被本地提权或误挂载容器读取。应绕过该文件存储：
- 配置
credsStore（如 Linux 上用pass，macOS 用osxkeychain，Windows 用wincred），使 docker login 将 token 存入系统密钥环而非 config.json - 对云厂商仓库（如 ECR、GHCR），优先使用
credHelpers，调用对应 CLI（如aws ecr get-login-password）动态获取短期 token，不持久化 - CI/CD 场景中，禁止
docker login持久化，改为每次构建前用临时 token 执行docker login -u AWS -p $(aws ecr get-login-password) https://xxx.dkr.ecr.region.amazonaws.com
禁用不安全的本地通信方式
Docker Client 默认通过 Unix socket（/var/run/docker.sock）与守护进程通信。若该 socket 权限宽松或被挂入容器，攻击者可直接调用 API 获取镜像层、甚至逃逸：
- 确保
/var/run/docker.sock权限为srw-rw----，且仅属主和 docker 组可访问 - 禁止将
/var/run/docker.sock挂载进不可信容器（尤其是 CI runner 容器） - 如需远程调用 Docker API，必须启用 TLS 并验证客户端证书，禁用裸 TCP 监听（即不设
-H tcp://0.0.0.0:2375）
