4.2 KiB
18.3 服务端防护
Docker 守护进程（dockerd）是容器生命周期的核心驱动力。默认情况下，Docker 服务的运行需要极高的系统特权（root 权限），因此其安全性关系到整台宿主机的生死存亡。
如果 Docker 守护进程的访问控制没有做好，恶意攻击者可以通过 Docker API 轻易地启动一个特权容器，并将宿主机的根目录（/）挂载到容器中，从而完全接管服务器。
为了加强对服务端的保护，我们需要从访问控制、通信加密和权限最小化三个维度进行加固。
18.3.1 限制 API 访问
Docker 客户端（docker 命令）通过 REST API 与守护进程进行通信。
在早期版本中，Docker 有时会绑定在 127.0.0.1 的 TCP 套接字上，但这容易遭遇跨站脚本（跨协议）攻击。现在的发行版默认使用 Unix Domain Socket（/var/run/docker.sock）并依赖文件系统的权限控制。
原则 1：决不可将无认证的 TCP 端口暴露在公网
这是最常见的 Docker 被入侵抓去挖矿的原因！绝不能在没有任何安全控制的情况下强行开启 -H tcp://0.0.0.0:2375。
如果业务确实需要远程访问 Docker 守护进程，必须启用 TLS 认证机制，让客户端和服务端互相进行证书校验。
开启 TLS 认证双向加密
利用安全机制，确保只有经过授权的主机网络，并在强证书保护下进行通信：
- 首先使用
openssl或基于本地 CA 工具生成一套客户端与服务器的证书。 - 配置 Docker 守护进程（通常是
daemon.json或dockerd启动参数），指定证书路径：
dockerd \
--tlsverify \
--tlscacert=ca.pem \
--tlscert=server-cert.pem \
--tlskey=server-key.pem \
-H=0.0.0.0:2376
- 客户端想要连接时，也必须出示客户端证书。
Tip
配置 TLS 生成证书的完整步骤可以查阅 Docker 官方 TLS 文档。在现代编排系统（如 Kubernetes）中，通常会有自动化方案管理这些凭据。
18.3.2 保护本地 Socket 访问
哪怕不开启网络端口，本地的 /var/run/docker.sock 也需要谨慎对待。
任何被授予该 Socket 读写权限的用户（通常被加入 docker 用户组），等同于拥有了对宿主机的零成本提权途径，即“无需密码的免密 sudo 权限”。
Caution
永远不要将不可信的普通用户加入到
docker用户组中。同样，在容器编排时尽量避免将宿主机的/var/run/docker.sock直接映射给普通容器使用，这种模式被称为 Docker-in-Docker (DinD) 或 Docker-out-of-Docker (DooD)，存在极高的越权风险。
18.3.3 Rootless 模式 (非特权运行)
为了从根本上解决“拥有 Docker socket 就是 root”的问题，Docker 在近年推出了 Rootless 模式。
Rootless 模式允许在完全局限于非 root 用户的环境中运行 Docker 守护进程（dockerd）和容器。该模式利用了现代 Linux 内核的 User Namespace 技术和非特权网络命名空间实现。
配置运行 Rootless Docker
要在非 root 环境中运行 Docker，只需要简单几步：
- 安装必要的依赖（通常是
uidmap工具包以便系统支持newuidmap和newgidmap）：
$ sudo apt-get install uidmap
- 切换到一个没有任何
sudo权限的普通用户（假设用户名为testuser）：
$ su - testuser
- 运行 Docker 官方提供的 Rootless 安装脚本：
$ curl -fsSL https://get.docker.com/rootless | sh
- 配置环境变量指向新创建的私有 socket：
$ export DOCKER_HOST=unix:///run/user/1000/docker.sock
$ docker version
安装并暴露相应的配置后，该用户的环境将能独立启动属于他自己的 Docker Daemon。即使由于某些未知 0-Day 漏洞使得攻击者突破了容器，他们也只会受限于 testuser 这个非特权用户所在的有限系统环境内。
18.3.4 结语
保障 Docker 服务端的安全主要是做减法：关闭不必要的网络监听点，严管 Socket 访问权限。而一旦基础系统条件允许，毫不犹豫地在生产环境启用 Rootless 模式将是一项划算的安全加固选择。