容器是IT领域最热门的软件理念。共享虚拟机通用部分这一概念——包括共享操作系统，管理工具，甚至应用程序，减少了任意镜像占用内存的这一主要因素，同时节省了网络带宽与许多副本上加载的基本相同的代码。
这些节省意义很大，初步估计容器支持降低三到五倍的实例数量，相比于某些情况下的传统的基于虚拟机管理程序的方法显得更加有效，例如在VDI市场的应用。值得注意的是，容器的创建和部署仅需要虚拟机的小部分时间和空间。
容器在经济性方面要比基于虚拟机管理程序的虚拟化好很多，然而容器是一项新技术，不成熟且还需要经过很多我们了解的虚拟化方式普及中曾经遇到过的问题。虽然许多公司都在不同层面利用容器进行工作，大多数人还是会承认有一些担心。
爆发的担忧
最关键的问题是多租户保护。虚拟机管理程序已经远远超过了十年，而且更重要的是，经历了许多CPU的产品周期。英特尔和AMD已经在虚拟机管理程序中添加相应功能，防止有关的内存交叉使用的行为。
这些功能的保护系统在本地没有存储驱动器，但本地用于加速应用程序实例的出现，意味着数据会被擦除，特别是SSD的数据，可能会在不同租户间被暴露。虚拟机管理程序供应商随机应变，现在将区块标记成未写入的状态。如果一个实例试图读取某一尚未写入的区块，虚拟机管理程序会发送全零指令并隐藏相关区块的所有数据。
没有这些保护功能，虚拟机管理程序将很不安全，任何人可以通过其他实例来获取数据的访问权。在某一服务器中的所有容器间，共享某一单独的操作系统镜像，能将硬件内存保护措施无效化，这就是并不成熟的容器技术在发展中所遇到的存储问题。
这两个问题可以通过在虚拟机中运行容器来缓解。这将保护在某一虚拟机中的容器无法被其他虚拟机通过交叉内存漏洞访问，同时虚拟机管理程序提供了所需的存储保护。包括Azure在内的所有主流云与虚拟机管理程序，现在都支持容器技术。
保护机制可能需要一定成本，尽管如此，因为在大量构建虚拟机规模之时需要优先创建容器。这两项技术运行在不同的时间尺度上，容器部署时间以毫秒计算，虚拟机部署则以秒计算。即使存在这些限制，基于虚拟机的容器是一种可行的方法，也是截至目前最常见的部署方法。业内已经在努力发展轻量级的虚拟机管理程序。例如，英特尔纯净容器技术(Intel Clear Containers)是一个以创建容器为目的的虚拟机管理程序。在其他方面，它使用核心的同页合并来安全地共享内存页之间的虚拟机，从而减少内存占用。VMware还支持容器，鉴于该公司在虚拟化方面的优势，对许多部门的运营方面的信心有重要作用。
用户访问控制
除了多租户问题，容器还存在特权升级的风险，某一应用程序获得根访问权限后，便可以获得主机的控制权。另一个问题是一个拒绝服务(Denial-Of-Service)攻击，或者即使是某个由bug造成的问题，所有的资源都能被某一单一容器控制。这些问题在容器环境中更容易出现。举例来说，Docker与主机系统的共享其命名空间，这种情况在基于虚拟化管理程序的环境中是永远不会出现的。
越权攻击可以通过启动时选择普通用户而非根用户的方式来缓解。在Docker中，这表示要在启动命令中加入代码-u。通过去掉SUID来启动这一修正。容器间独立的命名空间可以有效限制恶意软件控制服务器的存储空间。控件组可用于设置资源限制，并阻止拒绝服务攻击吸收服务器的资源。
中毒的镜像
是容器免受攻击的另一重保护，特别是在私有云，是使用受信任的公共库的镜像。今天，几乎所有的混搭使用代码都是用公共库的源代码来构建应用程序。这节省了巨大的开发时间和成本，因此对于IT预算紧张的应用场景，此种方式就显得很有实践意义。然而，大量的安全隐患也同时存在。即使是“高级”的库也可能会传播恶意软件，并且在最近的案例中发现，这样的代码已隐藏在流行的代码库有很多年。
来自受信任库的代码仍然容易受到病毒的侵入。对当今所使用的任何环境，镜像的控制都是关键问题，而不仅仅针对容器。使用支持镜像签名的可信任库，并当镜像加载到库中时，使用这些签名来验证，通过验证后再放行进入容器。这些服务是用来进行签名验证的，同时正确使用这些服务将保护你免受恶意软件的渗透。Docker Hub和Quay是两款可以信任的公共容器注册室。
另一个问题在容器上不是很明显，但在使用容器的传统微服务环境下比较严重，即用户所期望控制它们所运行的程序混搭。这使得存储库控制有点像溜猫。兼具源标识和签名检查的强制用户级验证对于稳定和安全的环境至关重要。在GitHub的Docker安全测试是一种能够检查许多已知安全问题的功能。为用户访问而建设自己的验证镜像库可能是这种方法的最终体现，但缺点在于，程序员很难保持一致并且缺乏灵活性，而库管理员能够几乎可以确定绕过这一验证机制。任何存储库都必须具有非常严格的安全机制，当从第三方存储库获取镜像时，确保其对用户端没有写入权限。要提高镜像库的管理水平，可考虑使用泊Docker的注册服务器或CoreOS Enterprise Registry。
验证和加密
对镜像中的应用程序和操作系统的版本控制是与漏洞有关的区域。同样，这不仅是容器特有的问题，但容器极其快速的变革和Docker对操作代码结构的取代趋势，并将他们替换成新版本是需要很强的制度约束。错位的版本通常提供会提供攻击的可能。
镜像扫描工具可用来自动化镜像并完成文件验证。Docker上有Nautilus工具，而CoreOS上则有Clair工具。如何进行静态或动态下的镜像加密问题仍然悬而未决。一般来说，漏洞文件的加密保护越多，我们要对抗勒索软件就越困难。对于镜像，加密应该起到阻止病毒或木马攻击镜像代码，并且再加上签名扫描和验证列表，便可远离勒索软件。在这方面，镜像相对于虚拟机管理程序有着明显的优势。与周围许多的镜像文件相比，服务器上的加密和解密负载要少得多。
容器守护进行时另一个漏洞点。它是管理容器的进程，并且如果被攻陷，便可以访问系统中的任何内容。限制访问是在保证守护进程安全的第一步。如果守护进程在网络上运行，那么加密传输是必要的，而使用小型化的Linux配置能够有效减少被攻击的可能。
有了上述的这些，我们便有了创建容器和建立其镜像的安全环境的基础。保护运行中的容器栈仍需继续努力。在监控区有个很不错的初期活动处理方法，它为控制动荡的实例混合提供了第一步的可能。CAdvisor是一款很好的容器监控开源工具，同时Docker提供数据命令。这些工具能够独立保证数据过载，因此它们的输出需要输入合适的分析软件包，像Splunk或Sumo Logic’s Docker 日志分析应用程序那样。通过建立正常操作的基线，任何由于恶意软件造成的异常访问的痕迹，都可以阻止并修复。
容器技术在短短几年里已经有了长足的发展。安全的环境确实需要很强的制度约束，但显而易见的是容器社区在相关领域，如镜像管理方面处于领先态势。
我们可以期待在未来1-2代的CPU中将出现对容器的硬件原生支持，就像CPU和当今的虚拟机管理程序配合那样。当其成为现实时，我们可以期待简化的裸金属容器部署的实现。未来还有许多挑战，如将软件定义的基础设施集成到容器的生态系统之中。容器在安全方面与虚拟机技术持平，同时在灵活性和部署速度方面更胜一筹。
本文转自d1net（转载）
