如何通过开启 TLS 双向认证防止黑客利用远程 API 篡改容器

开启TLS双向认证（mTLS）是防止黑客通过Docker远程API篡改容器的最直接有效手段，需服务端证书覆盖所有访问入口（含IP/DNS的SAN）、CA根证书4096位RSA、daemon.json禁用明文端口并启用tlsverify:true、客户端严格校验证书且权限设为600。

开启 tls 双向认证（mtls）是防止黑客通过 docker 远程 api 篡改容器的最直接有效手段——它让服务器不仅证明自己是合法的，还强制客户端也“亮证”，没证书或证书无效就彻底拒绝连接，从源头切断未授权操作。

服务端证书必须覆盖所有访问入口（关键在 SAN）

黑客常利用 IP 或域名不匹配绕过校验。服务端证书（server-cert.pem）若缺少实际访问地址，客户端会因 SAN（Subject Alternative Name）校验失败而降级或报错，反而可能暴露明文端口风险。

• 生成时明确列出所有可能的访问方式：如 IP:192.168.5.100, IP:127.0.0.1, DNS:docker-prod.internal
• 若通过公网域名访问（如 docker.example.com），DNS 条目不可省略；仅内网使用，也要把所有运维、CI/CD 机器的访问 IP 全部写入
• CA 根证书（ca.pem）和私钥（ca-key.pem）务必用 4096 位 RSA，有效期建议设为 2–3 年，避免频繁轮换引入配置遗漏

daemon.json 必须关闭明文端口并启用严格验证

哪怕只留一个 tcp://:2375，就等于给攻击者留了后门。Docker Daemon 的配置文件不是“开了 TLS 就安全”，而是“只要没关明文，TLS 就形同虚设”。

• hosts 字段只保留 "tcp://0.0.0.0:2376" 和 "unix:///var/run/docker.sock"，绝对删除 tcp://:2375 类条目
• 启用 "tlsverify": true（不是 tls:true），这是开启双向认证的开关；单设 "tls": true 仅加密，不校验客户端证书
• tlscacert、tlscert、tlskey 三个路径必须是绝对路径，且 server-key.pem 权限严格设为 600，属主为 root:docker

客户端必须携带可信证书对，且不能跳过验证

很多团队配好了服务端，却在客户端用 --tlsverify=false 或直接连 :2375 调试，等于把锁打开再挂把装饰钥匙。

• Linux/macOS 下，把 ca.pem、client-cert.pem、client-key.pem 放入 ~/.docker/，且 client-key.pem 权限设为 600
• 推荐用环境变量统一控制：
  export DOCKER_TLS_VERIFY=1
  export DOCKER_HOST=tcp://192.168.5.100:2376
  export DOCKER_CA_PATH=$HOME/.docker
• 验证是否生效：运行 docker info | grep "Server Version"，能返回结果才代表 mTLS 握手成功；若报 x509: certificate signed by unknown authority，则 CA 未被信任

更轻量替代方案：用 SSH 上下文完全规避 TCP 暴露

如果不需要开放任何 TCP 端口（比如仅 CI/CD 或运维人员远程管理），SSH 上下文比 TLS 更简单、更可靠——它复用系统 SSH 通道，天然支持密钥认证、访问控制和审计日志，且无需维护证书生命周期。

• 本地执行：docker context create --docker host=ssh://[email protected] prod-env
• 切换后所有 docker 命令自动走 SSH：docker context use prod-env
• 服务器只需确保 deploy 用户有 docker 组权限，无需开放 2376 端口，也不用处理证书吊销、过期等问题