Docker TLS API 与 2376 端口
2376 是 Docker 守护进程 Remote API 的 TLS 版本端口。启用后服务端要求客户端出示由同一 CA 签发的证书，实现双向认证，是必须走网络远程管理 Docker 时的正确做法。需要明确的是：它的安全性完全建立在证书管理之上，客户端证书私钥一旦泄露或被复制，风险与开放 2375 完全相同，因此证书的有效期、签发记录与吊销流程必须一并规划。
基本信息
| 服务 | Docker Engine API over TLS |
|---|---|
| 协议 | TCP 与 TLS 双向认证 |
| 用途 | CI 远程构建、跨主机容器编排、集中管理 |
| 必备文件 | CA 证书、服务端证书与私钥、客户端证书与私钥 |
| 权限要求 | 客户端证书对应权限等同宿主机 root |
| 更优替代 | SSH 之上的 docker context |
典型使用场景
- CI/CD 流水线在构建机上远程构建镜像并推送到仓库
- 多台宿主机统一管理，由中央平台下发部署指令
- 监控与巡检工具按只读范围采集容器状态
- 跨环境调试：从开发机连测试环境排查容器问题
- 自动化运维脚本替代登录式操作，缩短交互链路
服务端启用 TLS
服务端启用 TLS
dockerd --tlsverify \
--tlscacert=/etc/docker/ca.pem \
--tlscert=/etc/docker/server-cert.pem \
--tlskey=/etc/docker/server-key.pem \
-H=unix:///var/run/docker.sock \
-H=tcp://0.0.0.0:2376 # 保留本地 socket，仅对有证书的客户端开放 TCP客户端连接验证
客户端连接验证
docker --tlsverify \
--tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem \
-H=tcp://host:2376 version # 成功返回则应继续核对权限范围
docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H=tcp://host:2376 ps2375 与 2376 对比
| 维度 | 2375 | 2376 |
|---|---|---|
| 加密 | 无，明文传输 | TLS 加密 |
| 客户端身份 | 不校验 | 要求出示可信证书 |
| 凭据泄露后果 | 任何人可控制宿主机 | 持有证书者可控制宿主机 |
| 适用边界 | 不存在合理场景 | 受控网络且证书管理到位 |
证书卫生与客户端侧准备
证书卫生与客户端侧准备
openssl x509 -in client-cert.pem -noout -dates -subject # 核对有效期与主体
# 客户端文件权限应收紧，避免被其他用户读取
chmod 600 cert.pem key.pem ca.pem
# 更省心的做法：让 docker 客户端走 SSH 上下文，不暴露 2376
docker context create remote --docker 'host=ssh://ops@192.0.2.10'签发出去的客户端证书不设有效期、不做吊销，等同于永久交出宿主机控制权；人员变动与设备丢失时必须走吊销流程。
第三方面板同样要查：Portainer 之类的管理组件可能把 docker.sock 以无认证方式再次转发到网络，即使 2376 配置正确，暴露面也可能从别处打开。
放行策略仍要收紧：即便启用了 TLS，也应把 2376 限制到指定 CI 或管理主机的地址，并在日志中记录调用来源，避免证书体系成为唯一的防线。