对于Docker使用的一些安全配置建议

介绍

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

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

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

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

所以安全性问题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容器方案，在安全性上完全可以达到商用标准。就是可能对实施人员的技术要求和门槛较高。