浅谈 Docker 安全合规建设

通过阅读网上帖子及浏览相关信息，大家可能会产生一种错觉：Docker 安全性不足，对 Docker 导入生产环境持保守态度。不过实际情况是，虽然我们需要对容器的安全性高度关注，但只要使用得当，完全可以成为一种不低于使用虚拟机或者裸机的安全、高效生产系统。

我个人更喜欢把容器比喻成一种沙箱（Sandbox）：每个应用程序都有自己的存储空间；应用程序不能翻过自己的围墙去访问别的存储空间的内容；应用程序请求的数据都要通过权限检测，假如不符合条件的话，不会被放行。是不是似曾相识？其实我们的 ISO 应用就是这种方式执行的。

回归正题，事实上，目前行业标准当中所包含的各种准则针对虚拟化技术进行了调整，对于任何想要保护数据的企业来说都可以起到很大帮助作用。使用针对特定行业的标准进行合规审查，可以在很大程度上保证信息处于最佳安全实践的保障之下。安全的信息环境对于企业、客户和员工来说都是至关重要的。

Docker 技术目前还没有对应的认证条款，由于比较新，在数据隔离方面是否能够达到要求还具有不确定性，Docker 的安全性也还不够强健，只要具备 Docker 权限的用户都可以对 Docker 容器进行所有的操作。这无疑将增加审核范围及边界的不确定性。

另外，Docker 在当前阶段还在快速推出更新版本，也存在不兼容的情况，等待未来版本和安全性问题解决之后或许会有文件来指导合规过程。目前我不推荐大家直接用于认证环境。

幸运的是，关于 Docker 这种虚拟化技术背景的产品，标准要求本身是没有变化的，可以按虚拟技术进行评估。我们可以在业务相关的环境当中将 Docker 作为虚拟化技术的使用准则之一。比如，在 PCI DSS 第 2.2.1 章节当中指出一个虚拟系统组件或者设备只能实现一项主要功能，这正是容器的特点之一。

对于非认证的生产及非生产环境，我这里有一些 Docker 使用上的经验和心得和大家分享一下：

内核安全

所有进程运行在同一个内核中，即使有多个容器，所有的系统调用其实都是通过主机的内核处理，因此该内核中存在的任何安全漏洞都有可能造成巨大影响。如果某套容器系统导致内核崩溃，那么这反过来又会造成整台主机上的全部容器毁于一旦。在虚拟机当中，情况则要好得多：传统的虚拟机同样地很多操作都需要通过内核处理，但这只是虚拟机的内核，并非宿主主机内核。因此万一出现问题时，最多只影响到虚拟系统本身。当然你可以说先攻破 Hypervisor，再攻破 SELinux，然后攻破宿主主机内核就可以控制宿主机上的所有虚拟机，先不说虚拟机发展这么多年存在的漏洞还有多少，光虚拟机内核 → Hypervisor → SELinux → 宿主主机内核这几层的隔离的安全性和容器就不是一个数量级上的。所以建议大家密切关注内核的安全。在内核安全的合规建设上，虚拟机和容器的要求是一致的，大家完全可以遵从当前的行业标准。

拒绝服务攻击

所有容器都共享同样的内核资源。如果某套容器能够以独占方式访问某些资源，那么与其处于同一台主机上的其它容器则很可能因资源匮乏而无法正常运转。这正是拒绝服务攻击（简称DDoS）的产生原理，即合法用户无法对部分或者全部系统进行访问。在这方面大家亦可参考虚拟机时代的经验，预估应用的资源消耗上限，设计更多的 Cgroups，用于控制那些打开过多文件或者过多子进程等资源的进程，对容器资源进行限制，如 CPU 使用率，内存上限等，虽然容器的隔离性没虚拟机那么彻底，但至少能保证业务的连续性。

镜像安全

还有一部分来自于镜像本身的安全。由于 Docker Hub 上的镜像成千上万，甚至国内各种 PaaS 云服务公司提供的镜像仓库，如果攻击者诱导用户下载由其精心设计的镜像，那么运行的主机与数据都将处于威胁之下。建议大家使用可靠来源甚至是官方的镜像，并检查是否存在篡改。同样的，大家还需要确保自己运行的镜像为最新版本，且其中不包含任何存在已知安全漏洞的软件版本。

用户权限

如果大家在容器内拥有 root 权限，那么在主机上亦将具备 root 身份。在系统中非 root 用户只要加入 Docker 用户组，就无需使用 sudo 的情况下运行 Docker 命令。同样，添加了 –privileged 参数运行的容器也将获得主机的完全控制权。这种情况，首先，建议大家尽量不要使用 –privileged 参数，若实在有业务需求，可以将所有需要 –privileged 参数的容器严格控制在一台或某几台主机以隔离其他容器。其次，建议大家配合 sudo 来增加用户的审计和日志功能，在 /ect/sudoers 中添加以下内容：user ALL=(ALL) /usr/bin/docker，这样 user 使用 Docker 命令的时候需要密码验证，并会在系统中记录所有的操作日志用于审计。

文件完整性

有些 Linux 系统的内核文件系统必须要 mount 到容器环境里，否则容器里的进程就会罢工。这给恶意进程非常大的便利，但是大部分运行在容器里的 App 其实并不需要向文件系统写入数据。基于这种情况，建议在 mount 时使用只读模式，如 –v /etc/localtime:/etc/localtime:ro。

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

原文链接：http://mp.weixin.qq.com/s?__biz=MzA5OTAyNzQ2OA==&mid=2649690923&idx=1&sn=3741c618f186058bae628cc4bb669bb3&scene=4#wechat_redirect