Docker 安全性探讨与实践：实践篇

Daniel Walsh 是计算机安全领域的专家，有 30 余年的从业经验，非常熟悉容器技术。他在开源网站上发表了两篇文章，一篇讨论Docker 的安全性，另一篇则着重介绍了RHEL 如何对Docker 的安全性进行了大量的增强。本文即是Dan 第二篇文章的梳理与讨论，主要讨论了Docker 存在的安全风险以及如何保证它的安全。

在接纳了“容器并不是全封闭”这种思想以后，开源社区尤其是红帽公司，连同Docker 一起改进Docker 的安全性，改进项主要包括保护宿主不受容器内部运行进程的入侵、防止容器之间相互破坏。Dan 的团队主要采取了层叠式安全机制，即用多层不同安全技术融合在一起包括资源和数据。这种方法的好处就是，开发者可以尽可能地增加安全防护层，如果一个恶意进程突破了某一层防护，紧接着还有下一层基于不同安全机制的防护。红帽企业版Linux（RHEL）7 专门为这种层叠式安全机制提供了可选的安全技术，具体如下：

1. 文件系统级防护

• 文件系统只读：有些 Linux 系统的内核文件系统必须要 mount 到容器环境里，否则容器里的进程就会罢工。这给恶意进程非常大的便利，但是大部分运行在容器里的 App 其实并不需要向文件系统写入数据。基于这种情况，开发者可以在 mount 时使用只读模式。比如下面几个：

  • . /sys
  • . /proc/sys
  • . /proc/sysrq-trigger
  • . /proc/irq
  • . /proc/bus

  用只读模式的好处是，那些在容器里权限比较高的进程也无法向宿主文件系统写入。当然这里需要注意一点，必须要把这些进程 remount 可读写文件系统的能力给禁止。更进一步开发者甚至可以禁止容器 mount 任何文件系统，这需要通过使用 capability 完成，下面会详细解释。

• 写入时复制：Copy-on-write 的具体解释请读者参考前面的维基百科链接。Docker 采用的就是这样的文件系统。所有运行的容器可以先共享一个基本文件系统镜像，一旦需要向文件系统写数据，就引导它写到与该容器相关的另一个特定文件系统中。这样的机制避免了一个容器看到另一个容器的数据，而且容器也无法通过修改文件系统的内容来影响其他容器。

2. Capability 机制

Linux 对 Capability 机制阐述的还是比较清楚的，即为了进行权限检查，传统的 UNIX 对进程实现了两种不同的归类，高权限进程（用户 ID 为 0，超级用户或者 root），以及低权限进程（UID 不为 0 的）。高权限进程完全避免了各种权限检查，而低权限进程则要接受所有权限检查，会被检查如 UID、GID 和组清单是否有效。从 2.2 内核开始，Linux 把原来和超级用户相关的高级权限划分成为不同的单元，称为 Capability，这样就可以独立对特定的 Capability 进行使能或禁止。

通常来讲，不合理的禁止 Capability，会导致应用崩溃，因此对于 Docker 这样的容器，既要安全，又要保证其可用性。开发者需要从功能性、可用性以及安全性多方面综合权衡 Capability 的设置。Dan 在文中给出了 Docker 现有的 Capability 清单：chown、 dac_override、 fowner、 kill、 setgid、 setuid、 setpcap、 net_bind_service、 net_raw、 sys_chroot、 mknod、 setfcap 以及 audit_write。目前 Docker 安装时默认开启的 Capability 列表一直是开发社区争议的焦点，作为普通开发者，可以通过命令行来改变其默认设置。熟悉 Linux 内核的读者会发现，Docker 提供的 Capability 是相对较少的。Dan 在文中给出了 Docker 移除的 Capability 列表，并以 CAP_NET_ADMIN 为例，强调容器的设计应该是启动时配置好网络，而非从其内部修改，解释了容器安全性和 Capability 的 权衡，感兴趣的读者可以深入阅读。

3. NameSpace 机制

Docker 提供的一些命名空间也从某种程度上提供了安全保护，比如 PID 命名空间，它会将全部未运行在开发者当前容器里的进程隐藏。如果恶意程序看都看不见这些进程，攻击起来应该也会麻烦一些。另外，如果开发者终止 pid 是 1 的进程命名空间，容器里面所有的进程就会被全部自动终止，这意味着管理员可以非常容易地关掉容器。此外还有网络命名空间，方便管理员通过路由规则和 iptable 来构建容器的网络环境，这样容器内部的进程就只能使用管理员许可的特定网络。如只能访问公网的、只能访问本地的和两个容器之间用于过滤内容的容器。

4. Cgroups 机制

主要是针对拒绝服务攻击。恶意进程会通过占有系统全部资源来进行系统攻击。Cgroups 机制可以避免这种情况的发生，如 CPU 的 cgroups 可以在一个 Docker 容器试图破坏 CPU 的时候登录并制止恶意进程。Dan 表示，需要设计更多的 cgroups，用于控制那些打开过多文件或者过多子进程等资源的进程。类似的在文中 Dan 还介绍了设备 cgroups。

5. SELinux

SELinux 是一个标签系统，进程有标签，每个文件、目录、系统对象都有标签。SELinux 通过撰写标签进程和标签对象之间访问规则来进行安全保护。它实现的是一种叫做 MAC（Mandatory Access Control）的系统，即对象的所有者不能控制别人访问对象。具体可以参见 Dan 的这篇文章。至于如何用SELinux 来进行容器的安全防护，Infoq 会有另一篇文章来详细介绍Dan 的思想。

总而言之，为了保证Docker 容器的安全性，Dan 的团队尝试了非常多的安全机制，但是正如之前一篇文章中讲的，安全不在于机制的健全，而在于管理员自身的防范。在文章的结尾，Dan 给出了管理员应该注意的一些事项，如只运行来自可信来源的应用，在安全防护比较好的宿主机上运行等等。

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。