如何通过配置DockerClient的安全环境防范中间人攻击窃取凭证

作者：袖梨 2026-06-17

核心在于阻断凭证在传输和存储环节被截获：强制HTTPS并校验证书、启用mTLS双向认证、凭据不落盘而交由系统密钥环或临时token管理、禁用不安全的Docker守护进程通信方式。

防范中间人攻击窃取 Docker 凭证，核心在于阻断凭证在传输和存储环节被截获的路径。重点不是“配置 Docker Client”本身，而是确保它只通过可信通道通信、不落盘明文凭据，并启用双向身份验证。

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 要求客户端也提供证书，实现强身份绑定：

为 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