从Docker容器漏洞谈Docker 安全

　　近日，一篇在Docker博客上发表的文章显示，Docker的容器已经被突破，并且能够遍历宿主机的文件了。由于Docker的轻量，快速等等优点，让Docker在PaaS[注]领域愈发火热，自然也就吸引了安全人员对其进行研究。这篇文章无疑将Docker推进了一个新纪元：放开应用，想想安全。

　　不要给用户root权限

　　该文章的作者强调：只有在容器内以 root 权限运行不受信任的应用程序，才有可能触发这个漏洞。而这是我们不推荐的运行 Docker Engine 的方式。

　　这句话可以分两个层次来解读，首先就是root权限的使用，其次是何为不受信任的应用程序。

　　Docker并不是虚拟机，Docker本来的用法也不是虚拟机。举个简单的例子，普通的虚拟机租户root和宿主root是分开的，而Docker的租户root和宿主root是同一个root。一旦容器内的用户从普通用户权限提升为root权限，他就直接具备了宿主机的root权限，进而进行几乎无限制的操作。这是为什么呢？因为Docker原本的用法是将进程之间进行隔离，为进程或进程组创建隔离开的运行空间，目的就是为了隔离有问题的应用，而进程之间的限制就是通过namespace和cgroup来进行隔离与配额限制。每一个隔离出来的进程组，对外就表现为一个container(容器)。在宿主机上可以看到全部的进程，每个容器内的进程实际上对宿主机来说是一个进程树。也就是说，Docker是让用户以为他们占据了全部的资源，从而给用户一个“虚拟机”的感觉。

　　第二，何为不受信任的应用程序？来源不明的应用程序，或者二进制代码等等，以及有漏洞的应用程序，都可以称为不受信任的应用程序。举个例子，在Docker容器中只运行基础的Apache服务器和MySQL数据库，可能大家认为这样的环境用root也没问题，但是如果Apache或者MySQL有不为人所知的漏洞被利用，那么这两个应用也就成为了不受信任的应用。因此在以root运行应用程序，或是在考虑安全环境的时候，需要以一切皆不可信的态度来对Docker环境进行安全加固。

　　Docker安全要依靠辅助机制

　　该作者还强调，如果坚持要root权限使用 Docker Engine ，系统的安全性可能会受到一系列众所周知的内核安全漏洞的影响。因此特别建议：

　　· 在运行 Docker Engine 的系统中同时运行 AppArmor 或者 SELinux。

　　· 将机器分成不同的组，相互信任的容器划在一组。

　　· 不要以 root 权限运行任何不受信任的应用程序。

　　在上述三条建议之上，还应该有一种机制，就是保障机制。要不停的轮序去检测，要能够发现可疑的行为，并且对任何可疑的行为进行反应。比如进程A并未给root权限，但是后来通过检测机制发现它变成了root权限，我们就可以怀疑它是进行了非法提权的操作。也就是说，我们允许你逃逸，但是我们也能够在最短的时间内发现你的逃逸行为，并且制止你。

　　此外，Docker在安全方面还存在亟待加固的点：login过程使用明文传输用户名和密码，Image分发认证、Docker对Host的逃逸(已公布的那个漏洞)、Docker内给租户的root账号能否提供、Docker的配额限制(磁盘、网络)、Docker内万一提权后的限制(SELinux/AppArmor/GRSecurity)、出入Docker流量的监控和审计、AUFS存在的攻击点。

　　由于Docker需要把若干个container组一个虚拟的私有内网，解决租户之间的网络隔离。目前缺乏完整方案。从网络性能来分析，现状一般通过Docker Bridge或OVS实现NAT、用IPtable做隔离，性能堪忧，需要测试和验证。也有同仁表示性能衰减在50%以上。因此性能衰减严重也就可能成为一个新的攻击平面。在网络方面的攻击点存在container之间的嗅探、ARP攻击，IPtable的漏洞利用、对IPtable饱和攻击等等。

　　当然，绝大多数的Docker安全问题都是建立在被用在公有云[注]环境下的，如果Docker被使用在私有云[注]环境中，那么它所带来的好处要远远多于他带来的问题。