评估 Docker 安全性

理解 Docker 安全性的这三个核心方面，对于安全地部署和管理 Docker 容器至关重要。

由内核的命名空间和控制组机制提供的容器内在安全

这是 Docker 安全的基础，它利用了 Linux 内核本身的功能来提供隔离和资源限制。

内核命名空间

命名空间的作用是 隔离。它让容器认为自己拥有一个独立的系统环境，而不知道其他容器或宿主机也在运行。Docker 主要使用了以下命名空间：

• PID 命名空间：
  • 功能： 隔离进程 ID。每个容器都有自己的 PID 1 进程（通常是 init 系统或应用进程），它看不到宿主机或其他容器中的进程。
  • 安全意义： 阻止了容器内进程通过 PID 向宿主机或其他容器发送信号（如 kill -9），提供了进程间的隔离。
• Network 命名空间：
  • 功能： 为每个容器提供独立的网络栈，包括网络接口、IP 地址、路由表、端口号等。
  • 安全意义： 容器默认拥有私有的 IP 地址，需要通过端口映射才能被外部访问。这防止了容器随意监听宿主机网络或干扰其他容器的网络流量。
• Mount 命名空间：
  • 功能： 隔离文件系统挂载点。每个容器只能看到自己的文件系统视图，无法访问其他容器或宿主机的未挂载目录。
  • 安全意义： 这是文件系统隔离的关键。防止容器访问或篡改宿主机的敏感数据（如 /etc， /proc）。
• UTS 命名空间：
  • 功能： 允许容器拥有自己的主机名和域名。
  • 安全意义： 次要的安全隔离，防止容器修改宿主机的主机名。
• IPC 命名空间：
  • 功能： 隔离进程间通信资源，如信号量、消息队列和共享内存。
  • 安全意义： 阻止容器通过 IPC 机制与宿主机或其他无关容器进行通信。
• User 命名空间：
  • 功能： 这是 最关键也是最强大的 安全命名空间。它允许将容器内的用户 ID 和组 ID 映射到宿主机上不同的（通常是非特权的）用户 ID 和组 ID。
  • 安全意义： 容器内的 root 用户（UID 0）可以被映射到宿主机上的一个非特权的高位用户 ID（如 UID 100000）。这意味着，即使攻击者在容器内获得了 root 权限，它在宿主机上执行的操作也受到其映射到的非特权用户的权限限制，极大地减少了“容器逃逸”带来的影响。默认情况下，Docker 不启用 User Namespace，需要手动配置。

控制组

控制组的作用是 限制和审计。

• 功能： Cgroups 用于限制容器可以使用的资源上限，包括：
  • CPU： 设置 CPU 份额或绑定到特定 CPU 核心。
  • 内存： 设置硬性和软性内存限制。
  • 块设备 I/O： 限制磁盘的读写带宽。
  • 网络 I/O： 虽然主要由网络命名空间处理，但也可以通过其他工具配合 cgroups 进行限制。
• 安全意义：
  • 防止拒绝服务攻击： 确保单个行为异常或恶意的容器不会耗尽宿主机的所有资源（如内存、CPU），从而导致系统瘫痪或其他容器被“饿死”。
  • 确保服务质量： 为关键容器保障必要的资源。
  • 提供审计： 统计容器的资源使用情况。

小结： 命名空间和 Cgroups 共同构成了容器的“沙箱”，提供了基础的隔离和资源控制。但 它们并非无懈可击，历史上曾出现过利用内核漏洞突破命名空间隔离的案例。

Docker 程序（特别是服务端）本身的抗攻击性

Docker 采用客户端-服务器架构。守护进程 dockerd 以 root 权限运行，这是整个体系中最主要的安全攻击面。

Docker 守护进程的攻击面

• REST API： Docker 守护进程监听一个 Socket（通常是 Unix 套接字 /var/run/docker.sock，有时也可能是 TCP 端口）来接收来自 docker 客户端的命令。
• 安全风险：
  • 任何能访问到 Docker Socket 的用户或进程，本质上就获得了在宿主机上执行任意命令的权限（因为 dockerd 以 root 运行）。例如，他们可以通过 docker run -v /:/host ... 将宿主机根目录挂载到容器中，从而完全控制宿主机。
  • 如果错误地将 Docker API 暴露在 TCP 端口且没有适当的认证和加密，那么网络上的任何人均可控制 Docker 守护进程。

安全最佳实践

• 严格保护 Docker Socket： 永远不要将 docker.sock 暴露给不可信的容器。在容器内挂载 docker.sock 是一种常见的 CI/CD 模式，但这等同于将 root 权限交给了该容器，需要极其谨慎。
• 使用非 root 用户运行守护进程： 较新版本的 Docker 支持以非 root 用户运行守护进程，这可以减轻攻击影响。
• 启用 TLS 认证： 如果必须使用 TCP 连接，务必配置 TLS 双向认证，以确保只有授权的客户端才能连接。
• 定期更新： Docker 本身也可能存在漏洞，需要保持最新版本，以获取安全补丁。

小结： Docker 守护进程是一个高权限、高价值的目标。其安全性很大程度上依赖于配置的合理性和对访问权限的严格控制。

内核安全性的加强机制对容器安全性的影响

由于命名空间和 Cgroups 并非绝对安全，我们需要额外的安全层来“加固”内核和容器，这就是“纵深防御”策略。

Capabilities

• 概念： Linux Capabilities 将 root 用户的超级权限分解为一系列独立的权限单元。
• Docker 的应用： 默认情况下，Docker 容器在启动时只被授予一个 受限的 能力集合，即使容器内以 root 运行。例如，默认被移除的能力包括：
  • CAP_SYS_MODULE: 禁止加载内核模块。
  • CAP_SYS_ADMIN: 禁止执行大量系统管理命令。
  • CAP_NET_RAW: 禁止创建原始套接字（防止 ping 等）。
• 安全实践：
  • 原则： 使用 --cap-drop 移除所有能力，然后仅通过 --cap-add 添加应用运行所必需的最小能力集。
  • 示例： docker run --cap-drop ALL --cap-add NET_BIND_SERVICE ...

Seccomp

• 概念： Seccomp 是一种内核安全机制，用于限制进程可以执行的系统调用。
• Docker 的应用： Docker 提供了一个默认的 Seccomp 配置文件，它白名单了大约 300 个系统调用，并禁用了大约 40 个被认为危险或不必要的系统调用（如 swapon, swapoff, reboot）。
• 安全实践： 可以使用自定义的 Seccomp 配置文件，进一步收紧系统调用的访问，为特定应用量身定制最严格的策略。

AppArmor 和 SELinux

• 概念： 它们是强制访问控制系统，可以为进程定义其可以访问的文件、网络端口等资源的精细策略。
• Docker 的应用：
  • Docker 默认会为容器生成并加载一个 AppArmor 配置文件（如果宿主机支持）。
  • 这个默认策略阻止了容器进行许多危险操作，例如写入 /proc 和 /sys 下的某些文件。
• 安全实践： 可以编写自定义的 AppArmor 或 SELinux 策略，为容器提供更强的强制访问控制。

其他加固技术

• 无特权容器： 使用 User Namespace，如前所述，是最大的安全改进之一。
• 只读根文件系统： 使用 --read-only 标志启动容器，防止恶意代码写入文件系统。
• 安全计算模式： 使用 --security-opt seccomp=... 应用自定义 Seccomp 策略。

总结

评估 Docker 安全性是一个多层次的过程：

1. 基础隔离层： 依赖 Linux 内核的 命名空间和控制组。这是容器技术的基石，提供了基本的沙箱环境，但存在被内核漏洞攻破的风险。
2. 程序攻击面： Docker 守护进程 本身是一个关键风险点，必须通过严格的访问控制和网络加密来保护。
3. 纵深防御层： 利用 Capabilities、Seccomp、AppArmor/SELinux 等内核安全机制，遵循“最小权限原则”，极大地提升容器的安全性，即使基础隔离被突破，也能有效遏制攻击。

一个安全的 Docker 部署，必然是这三个方面协同作用的结果，缺一不可。

内核命名空间

您可以把 Docker 容器想象成一个 装修好的酒店房间。

• 命名空间 = 房间的墙和门锁
  • 它提供了最基本的 隔离。你在你的房间里活动、睡觉，不会被走廊或其他房间的客人看到或打扰（进程隔离）。
  • 每个房间都有独立的 门牌号和钥匙（网络栈）。你无法直接进入另一个房间，除非酒店（宿主机）在前台为你们建立了联系（比如通过端口映射或 Links）。
• 网络通信 = 酒店的内部电话系统
  • 所有房间（容器）都通过酒店的总机（主机的网桥接口）相互联系。要打电话给另一个房间，你需要知道对方的房间号，并通过总机转接。这就像物理机器通过一台共享的交换机来通信。

那么，这套“建房间”的技术可靠吗？非常可靠。

• 历史悠久：支撑 Docker 容器的核心技术（Linux 命名空间）在 2008 年 就已经被加入到主流 Linux 内核中了。这意味着它已经经历了超过 15 年的实践检验和持续改进。
• 久经考验：全球无数大型互联网公司（如 Google, Netflix）每天都在数百万台服务器上运行着容器，其稳定性和安全性已经得到了充分的证明。
• 源远流长：这个想法本身甚至更早，源于一个叫 OpenVZ 的成熟容器项目（2005 年）。Docker 使用的是经过长期打磨和验证的内核基础。

总结

1. 隔离可靠：Docker 使用 命名空间 为每个容器创建了独立的“小房间”，实现了有效的进程和网络隔离。
2. 通信可控：容器之间通过 主机网桥 通信，就像酒店总机转接电话，既方便又可控。
3. 技术成熟：这套底层技术 并非新技术，它已经发展了近二十年，非常稳定可靠，足以支撑当今最重要的商业应用。

控制组

控制组，可以理解为我们为容器设定的 “资源管理员”。

想象一下，在一台物理服务器上运行着多个容器，就像在一栋合租房里住了好几个室友。如果没有管理，有人可能会疯狂下载，占满所有网络；有人可能冬天把暖气开到最大，让其他人受冻。

控制组的作用就是 给每个室友（容器）设定规矩，确保大家能公平、和谐地共用房子（主机）的资源：

1. 资源限制（设定上限）：
   • 比如内存：可以明确规定“你的容器最多只能用 2GB 内存”，防止某个程序内存泄漏，吃光所有内存，导致整个主机瘫痪。
   • 比如 CPU：可以规定“你的容器最多只能使用 30% 的 CPU”，防止一个容器跑满 CPU，让其他容器和主机系统都卡死。
2. 资源保障（保证下限）：
   • 可以承诺“至少保证 10% 的 CPU 分配给你的容器”，这样即使系统很忙，你的关键服务也能获得最基本的资源，确保性能稳定。
3. 资源审计（计算账单）：
   • 控制组会记录每个容器到底使用了多少 CPU、内存、网络流量等。这对于成本核算、性能监控和故障排查非常有用。

为什么这很重要？

它的核心安全意义在于：确保一个“坏掉”或“恶意”的容器不会拖垮整个主机。这就像给合租房的每个房间都安装了独立的水电闸，一个房间漏水短路，不会淹了整栋楼。这在云服务平台上是必不可少的功能，因为它能有效防止因单个用户应用异常而导致的“拒绝服务”攻击。

总结

• 它是什么：控制组是 Linux 内核用于 限制、记录和隔离进程资源使用 的机制。
• 核心作用：确保容器 公平分享 主机资源（CPU、内存、磁盘 IO 等），并且 当一个容器出问题时，不会连累整个主机系统。
• 关键价值：它是实现多租户环境下稳定性的基石，能有效防止因资源争夺导致的系统瘫痪。

服务端防护

运行一个容器或应用程序的核心是通过 Docker 服务端。Docker 服务的运行目前需要 root 权限，因此其安全性十分关键。

首先，确保只有可信的用户才可以访问 Docker 服务。Docker 允许用户在主机和容器间共享文件夹，同时不需要限制容器的访问权限，这就容易让容器突破资源限制。例如，恶意用户启动容器的时候将主机的根目录 / 映射到容器的 /host 目录中，那么容器理论上就可以对主机的文件系统进行任意修改了。这听起来很疯狂？但是事实上几乎所有虚拟化系统都允许类似的资源共享，而没法禁止用户共享主机根文件系统到虚拟机系统。

这将会造成很严重的安全后果。因此，当提供容器创建服务时（例如通过一个 web 服务器），要更加注意进行参数的安全检查，防止恶意的用户用特定参数来创建一些破坏性的容器。

为了加强对服务端的保护，Docker 的 REST API（客户端用来跟服务端通信）在 0.5.2 之后使用本地的 Unix 套接字机制替代了原先绑定在 127.0.0.1 上的 TCP 套接字，因为后者容易遭受跨站脚本攻击。现在用户使用 Unix 权限检查来加强套接字的访问安全。

用户仍可以利用 HTTP 提供 REST API 访问。建议使用安全机制，确保只有可信的网络或 VPN，或证书保护机制（例如受保护的 stunnel 和 ssl 认证）下的访问可以进行。此外，还可以使用 HTTPS 和证书 来加强保护。

最近改进的 Linux 命名空间机制将可以实现使用非 root 用户来运行全功能的容器。这将从根本上解决了容器和主机之间共享文件系统而引起的安全问题。

终极目标是改进 2 个重要的安全特性：

• 将容器的 root 用户 映射到本地主机上的非 root 用户 ，减轻容器和主机之间因权限提升而引起的安全问题；
• 允许 Docker 服务端在 非 root 权限(rootless 模式) 下运行，利用安全可靠的子进程来代理执行需要特权权限的操作。这些子进程将只允许在限定范围内进行操作，例如仅仅负责虚拟网络设定或文件系统管理、配置操作等。

最后，建议采用专用的服务器来运行 Docker 和相关的管理服务（例如管理服务比如 ssh 监控和进程监控、管理工具 nrpe、collectd 等）。其它的业务服务都放到容器中去运行。

内核能力机制

能力机制（Capability） 是 Linux 内核一个强大的特性，可以提供细粒度的权限访问控制。 Linux 内核自 2.2 版本起就支持能力机制，它将权限划分为更加细粒度的操作能力，既可以作用在进程上，也可以作用在文件上。

例如，一个 Web 服务进程只需要绑定一个低于 1024 的端口的权限，并不需要 root 权限。那么它只需要被授权 net_bind_service 能力即可。此外，还有很多其他的类似能力来避免进程获取 root 权限。

默认情况下，Docker 启动的容器被严格限制只允许使用内核的一部分能力。

使用能力机制对加强 Docker 容器的安全有很多好处。通常，在服务器上会运行一堆需要特权权限的进程，包括有 ssh、cron、syslogd、硬件管理工具模块（例如负载模块）、网络配置工具等等。容器跟这些进程是不同的，因为几乎所有的特权进程都由容器以外的支持系统来进行管理。

• ssh 访问被主机上 ssh 服务来管理；
• cron 通常应该作为用户进程执行，权限交给使用它服务的应用来处理；
• 日志系统可由 Docker 或第三方服务管理；
• 硬件管理无关紧要，容器中也就无需执行 udevd 以及类似服务；
• 网络管理也都在主机上设置，除非特殊需求，容器不需要对网络进行配置。

从上面的例子可以看出，大部分情况下，容器并不需要“真正的” root 权限，容器只需要少数的能力即可。为了加强安全，容器可以禁用一些没必要的权限。

• 完全禁止任何 mount 操作；
• 禁止直接访问本地主机的套接字；
• 禁止访问一些文件系统的操作，比如创建新的设备、修改文件属性等；
• 禁止模块加载。

这样，就算攻击者在容器中取得了 root 权限，也不能获得本地主机的较高权限，能进行的破坏也有限。

默认情况下，Docker 采用 白名单 机制，禁用必需功能之外的其它权限。 当然，用户也可以根据自身需求来为 Docker 容器启用额外的权限。

什么是能力机制？

你可以把传统的 root 用户 想象成一把 “万能钥匙” ，拥有整个系统的所有权限。一旦把这把钥匙交给某个程序，它就可以在系统里为所欲为，这非常危险。

而 Linux 能力机制 则像是将这把“万能钥匙”拆分成了一系列 “专用门卡” ，比如：

• net_bind_service：是一张“网络端口门卡”，允许持卡程序绑定特定的网络端口。
• … 以及其他几十种不同的“门卡”，分别控制着加载内核模块、修改系统时间等特定权限。

这样一来，一个程序（比如 Web 服务器）无需拿到“万能钥匙”（root 权限），只需要领取它工作所必需的那张“门卡”（特定能力），就能完成它的任务。这大大减少了程序被滥用时的破坏范围。

Docker 如何利用能力机制加强安全？

Docker 深谙“最小权限原则”，默认情况下，它启动容器时只会授予一个非常小的白名单能力集，许多高风险的能力在默认情况下就被禁用了。

为什么这样做很安全且合理？ 因为在容器这个“小房间”里，很多需要 root 权限的系统管理任务，其实都由外面的“酒店管理方”（宿主机系统）承担了：

系统任务	在传统服务器中	在 Docker 环境中的情况
SSH 连接	由 sshd 进程（root权限）处理	由宿主机管理，容器内不需要
定时任务	由 cron 进程（root权限）处理	可作为用户进程运行，或由外部管理
硬件管理	由 udevd 进程（root权限）处理	与容器无关，无需此权限
网络配置	由 root 权限工具（如 ip, ifconfig）处理	主要由宿主机负责，容器只需使用网络

最终的安全效果是： 即使攻击者成功在容器内取得了 root 身份，由于 Docker 已经收回了大部分关键的“专用门卡”（能力），他能造成的破坏也极其有限。他无法挂载新设备、无法加载恶意内核模块、也无法直接操作宿主机的网络设备，从而无法从容器这个“小房间”逃逸到“酒店主体结构”（宿主机）中。

总结

1. 核心思想：能力机制将 root 的超级权限拆分为几十种细粒度的权限，实现了从“万能钥匙”到“专用门卡”的进化。
2. Docker的实践：Docker 默认采用白名单机制，只赋予容器所必需的最小能力集合，遵循了“最小权限原则”。
3. 安全价值：这极大地增强了容器安全性。即使容器被攻破，攻击者由于缺乏关键能力，也无法对宿主机造成严重影响，实现了有效的安全隔离。

简单来说，Docker 通过能力机制，既保证了容器能正常运行，又牢牢锁住了它通往宿主机的“后门”。

总结

总体而言，在合理配置下，Docker容器是相当安全的。其安全性在以下两种情况下会得到极大提升：

1. 最佳实践：在容器内不使用root用户来运行应用进程。
2. 纵深防御：使用现有的安全工具为容器增加额外的防护层。

这些安全工具就像是给容器穿上不同类型的“护甲”，共同构成纵深防御体系：

安全机制	通俗理解	在Docker中的作用
Seccomp	“系统调用过滤器”	限制容器内的进程只能使用一部分必要的系统调用（比如禁止调用“重启系统”的指令），大幅减少攻击面。
AppArmor/SELinux	“行为访问控制列表”	为容器定义一个严格的“行为守则”，明确规定它能够读、写或执行哪些文件、端口等，防止越权行为。
GRSEC	“增强型内核补丁”	通过对整个Linux内核打上安全补丁，提供一系列增强防护，从更底层保护主机和所有容器。

总结

1. 基础安全：Docker本身通过命名空间和控制组提供了良好的默认隔离。
2. 关键提升：在容器内以非root用户运行程序，是提升安全性的最简单、最有效的方法之一。
3. 高级加固：通过Seccomp、AppArmor或SELinux等工具，可以实施“最小权限”原则，为容器定制严格的安全策略，从而构建起坚固的纵深防御，即使应用存在漏洞，也能有效控制破坏范围。

因此，您可以相信，只要遵循基本的安全实践并善用现有工具，Docker容器环境完全可以满足生产级的安全要求。

只要严格遵循 Docker 安全最佳实践，并采用“纵深防御”策略，就可以在生产环境中构建起风险可控、足够安全的应用运行平台。

您可以对 Docker 的安全性抱有高度的信心。它提供了坚实的安全基础和一整套成熟的可用于加固的工具。只要您主动地、有意识地去配置和管理它，它就能成为一个用于生产环境的安全可靠的平台。 它的安全性不是自动获得的，而是正确实践的结果。