浅谈 Docker 隔离性和安全性

Question

相信很多开发者都默认 Docker 这样的容器是一种沙盒（sandbox）应用，也就是说他们可以用 root 权限在 Docker 中运行随便什么应用，而 Docker 有安全机制能保护宿主系统。比如，有些人觉得 Docker 容器里面的进程跟虚拟机里面的进程一样安全；还有的人随便找个源就下载没有验证过的 Docker 镜像，看都不看内容就在宿主机器上尝试、学习和研究；还有一些提供 PaaS 服务的公司竟然允许用户向多租户系统中提交自己定制的 Docker 镜像。请注意，上述行为均是不安全的。

本文将介绍 Docker 的隔离性和安全性，以及为什么它在隔离和安全性上不如传统的虚拟机。

更多信息

何谓安全性？

单单就 Docker 来说，安全性可以概括为两点：

1. 不会对主机造成影响
2. 不会对其他容器造成影响

所以安全性问题 90%以上可以归结为隔离性问题。而 Docker 的安全问题本质上就是容器技术的安全性问题，这包括共用内核问题以及 Namespace 还不够完善的限制：

• /proc、/sys 等未完全隔离
• Top, free, iostat 等命令展示的信息未隔离
• Root 用户未隔离
• /dev 设备未隔离
• 内核模块未隔离
• SELinux、time、syslog 等所有现有 Namespace 之外的信息都未隔离

当然，镜像本身不安全也会导致安全性问题。

真的不如虚拟机安全？

其实传统虚拟机系统也绝非 100%安全，只需攻破 Hypervisor 便足以令整个虚拟机毁于一旦，问题是有谁能随随便便就攻破吗？如上所述，Docker 的隔离性主要运用 Namespace 技术。传统上 Linux 中的 PID 是唯一且独立的，在正常情况下，用户不会看见重复的 PID。然而在 Docker 采用了 Namespace，从而令相同的 PID 可于不同的 Namespace 中独立存在。举个例子，A Container 之中 PID=1 是 A 程序，而 B Container 之中的 PID=1 同样可以是 A 程序。虽然 Docker 可透过 Namespace 的方式分隔出看似是独立的空间，然而 Linux 内核（Kernel）却不能 Namespace，所以即使有多个 Container，所有的 system call 其实都是通过主机的内核处理，这便为 Docker 留下了不可否认的安全问题。

传统的虚拟机同样地很多操作都需要通过内核处理，但这只是虚拟机的内核，并非宿主主机内核。因此万一出现问题时，最多只影响到虚拟系统本身。当然你可以说黑客可以先 Hack 虚拟机的内核，然后再找寻 Hypervisor 的漏洞同时不能被发现，之后再攻破 SELinux，然后向主机内核发动攻击。文字表达起来都嫌繁复，更何况实际执行？所以 Docker 是很好用，但在迁移业务系统至其上时，请务必注意安全性！

如何解决？

在接纳了“容器并不是全封闭”这种思想以后，开源社区尤其是红帽公司，连同 Docker 一起改进 Docker 的安全性，改进项主要包括保护宿主不受容器内部运行进程的入侵、防止容器之间相互破坏。开源社区在解决 Docker 安全性问题上的努力包括：

• Audit namespace
  • 作用：隔离审计功能
  • 未合入原因：意义不大，而且会增加 audit 的复杂度，难以维护。
• Syslognamespace
  • 作用：隔离系统日志
  • 未合入原因：很难完美的区分哪些 log 应该属于某个 container。
• Device namespace
  • 作用：隔离设备（支持设备同时在多个容器中使用）
  • 未合入原因：几乎要修改所有驱动，改动太大。
• Time namespace
  • 作用：使每个容器有自己的系统时间
  • 未合入原因：一些设计细节上未达成一致，而且感觉应用场景不多。
• Task count cgroup
  • 作用：限制 cgroup 中的进程数，可以解决 fork bomb 的问题
  • 未合入原因：不太必要，增加了复杂性，kmemlimit 可以实现类似的效果。(最近可能会被合入)
• 隔离/proc/meminfo 的信息显示
  • 作用：在容器中看到属于自己的 meminfo 信息
  • 未合入原因：cgroupfs 已经导出了所有信息，/proc 展现的工作可以由用户态实现，比如 fuse。

不过，从 08 年 cgroup/ns 基本成型后，至今还没有新的 namespace 加入内核，cgroup 在子系统上做了简单的补充，多数工作都是对原有 subsystem 的完善。内核社区对容器技术要求的隔离性，本的原则是够用就好，不能把内核搞的太复杂。

一些企业也做了很多工作，比如一些项目团队采用了层叠式的安全机制，这些可选的安全机制具体如下：

1、文件系统级防护

• 文件系统只读：有些 Linux 系统的内核文件系统必须要 mount 到容器环境里，否则容器里的进程就会罢工。这给恶意进程非常大的便利，但是大部分运行在容器里的 App 其实并不需要向文件系统写入数据。基于这种情况，开发者可以在 mount 时使用只读模式。比如下面几个： /sys 、/proc/sys 、/proc/sysrq-trigger 、 /proc/irq、/proc/bus
• 写入时复制（Copy-On-Write）：Docker 采用的就是这样的文件系统。所有运行的容器可以先共享一个基本文件系统镜像，一旦需要向文件系统写数据，就引导它写到与该容器相关的另一个特定文件系统中。这样的机制避免了一个容器看到另一个容器的数据，而且容器也无法通过修改文件系统的内容来影响其他容器。

2、Capability 机制

Linux 对 Capability 机制阐述的还是比较清楚的，即为了进行权限检查，传统的 UNIX 对进程实现了两种不同的归类，高权限进程（用户 ID 为 0，超级用户或者 root），以及低权限进程（UID 不为 0 的）。高权限进程完全避免了各种权限检查，而低权限进程则要接受所有权限检查，会被检查如 UID、GID 和组清单是否有效。从 2.2 内核开始，Linux 把原来和超级用户相关的高级权限划分成为不同的单元，称为 Capability，这样就可以独立对特定的 Capability 进行使能或禁止。通常来讲，不合理的禁止 Capability，会导致应用崩溃，因此对于 Docker 这样的容器，既要安全，又要保证其可用性。开发者需要从功能性、可用性以及安全性多方面综合权衡 Capability 的设置。目前 Docker 安装时默认开启的 Capability 列表一直是开发社区争议的焦点，作为普通开发者，可以通过命令行来改变其默认设置。

3、NameSpace 机制

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

4、Cgroups 机制

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

5、SELinux

SELinux 是一个标签系统，进程有标签，每个文件、目录、系统对象都有标签。SELinux 通过撰写标签进程和标签对象之间访问规则来进行安全保护。它实现的是一种叫做 MAC（Mandatory Access Control）的系统，即对象的所有者不能控制别人访问对象。

安全建议

最简单的就是不要把 Docker 容器当成可以完全替代虚拟机的东西。跑在 Docker 容器中的应用在很长一段时间内都将会是选择性的，通常只跑测试系统或可信业务。

门槛再高一点，我们对系统做减法，通过各种限制来达到安全性。这也是最主流的、有效的安全加固方法，比如上一章节介绍的几种安全机制。同时一定要保证内核的安全和稳定。外部工具的监控、容错等系统也必不可少。

总之通过适配、加固的 Docker 容器方案，在安全性上完全可以达到商用标准。就是可能对实施人员的技术要求和门槛较高。

参考

Docker 在线文档：Docker Security

OpenSource.com：Bringing new security features to Docker

InfoQ：从社区和内核看 Docker 隔离性和安全性发展