谈DevOps中的容器安全

【编者按】对比虚拟机，Docker在体量等方面拥有显著的优势。然而，当DevOps享受Docker带来扩展性、资源利用率和弹性提升的同时，其所面临的安全隐患同样值得重视，近日Chris Taschner在SEI上撰文进行了总结。

以下为译文

基于容器的虚拟化平台提供了一种方式在隔离的实例中运行多个应用程序。容器技术可以为DevOps提供显著的优势，包括提高系统的扩展性、资源利用率和弹性。然而除下容器与主系统完全解耦，这种使用就会存在潜在的安全隐患。因此，这篇博文主要描述了为什么系统管理员应该密切关在容器中运行应用所采纳的权限等级，以及用户访问主机系统的权限。

容器已经成为DevOps中的新热点技术。特别是Docker公司，已经成为了提供容器技术服务的领头公司。使用Docker平台，应用程序极其依赖可以被打包进一个单元，也就是所谓的镜像。随后，Docker就可以运行这个镜像的实例，每个镜像的实例都是在驻留在容器中。

Docker正成为DevOps的代名词。如果你还不熟悉容器的优势的话，概括地说，它们包括了可使用的镜像和易于使用的公共库、镜像版本，以及Docker的思想。（欲了解更多信息，请参见 devops.com上的Three Reasons We Use Docker）。

在谈到大小时，容器具有很多优势。不像虚拟机，一个容器不需要运行整个操作系统，或者对系统的硬件进行拷贝。容器仅仅只需要足够的操作系统和硬件信息资源来运行它负责托管的应用。所以，容器所消耗的资源比虚拟机小很多，因此同一主机上可以跑的容器肯定比虚拟机多。

而在最小化需要运行的容器上，开发者需要做好足够的权衡。其中一个就是减少容器与系统之间的分离度。与此相反，虚拟机与主机的分离性比容器的更高。Docker用户需要root用户权限去运行容器，如果Docker用户不知道容器中运行的是什么，这可能会引发问题。通常，那些repository都是未经过审核的，这意味着任何人都可以创建和上传镜像。显然，对从互联网上下载下来的容器给以太多的信任会引发安全问题。

共享命名空间的问题通常是Docker的最大问题。命名空间是系统内核所创建的组，它通常会为不同源和区域指定不同的访问级别。而究于扩展性，在Docker中并没有为容器提供不同的命名空间——倘若有数百个容器在运行，那么每个容器都需要有独立的命名空间。而且，如果一个容器想要共享存储，那么所有共享这个存储的命名空间必须使用显式访问。

在回应有关Docker的安全问题时，这里详细讨论了如何缓解Docker的安全问题。缓解方法的建议包括了限制直接访问主机和在容器中运行应用的权限。

除了Doker容器的安全指导，还有其它在确保容器安全方面的建议。共享命名空间的一个潜在解决方案是使用Seccomp，它是一个进程处理工具。Daniel Walsh 在opensource.com上详细地介绍了这项工作。

管理员必须清楚容器中运行的究竟是什么。从互联网上下载来的镜像应该仔细审核，然后才在敏感的环境中运行。一般规则，不像字面意义，容器不应是包含在容器内运行的应用程序。

原文链接：Container Security in DevOps（翻译/OneApm工程师，责编/仲浩）