容器给将安全性融入发展和操作过程中提供了一个千载难逢的机会，让我们把握住这个机会。

当企业开发应用程序时，安全性仍被看做是一个事后考虑项，在应用发布之前才会涉及。软件容器的迅猛发展，为把安全性纳入上游开发过程（或在devops术语中称为“左移”）提供了一个难得的机会，并成为早期综合性和整个软件交付的管道。然而，大多数安全团队不知道容器为何物，更不必说了解它们独特的安全挑战是什么了。

软件容器可以被认为是系统需求更为精简的轻量级虚拟器。在运行时，容器共享主机的操作系统内核，大大减少了信息处理量（只有兆字节），加快了运行速度。容器启动一个虚拟器仅需几秒而不是几分钟。

容器自21世纪初期就出现了，并于2007年被构架到Linux中。因其占用空间小和便携性，与虚拟器相比同样的硬盘可以支持更多的容器，极大的减少了基础设施成本，加快了更多应用程序的运行速度。

然而，由于可用性问题，容器并未流行，直到Docker加入后改善了其可用性和对企业的适用性。如今容器——和Docker——变得炙手可热。今年早些时候，摩根大通和梅隆银行公开表示，他们正在寻求一种基于容器的发展战略，证明了容器对传统企业的发展有巨大的推动力，就像云之于谷歌、优步和Yelp。

就像容器的卓越性一样，它们也带来了独特的新风险。通常情况下，只有在新技术出现时才会发生此类事件，因此安全意识并未构建在容器内部。如果容器不在你的雷达上，那么现在是时候加速了，因为它们很有可能已经在你们公司内部的某个地方开始运行。我列出了在使用容器时会面临的5个独特的问题。

1.容器图像中的漏洞管理

图像是构建容器的基石。开发人员可以轻易地创建自己的图像，或者从Docker 枢纽和其他集中开源注册中心下载公共图像。使容器的使用达到高度自动化，过程灵活。

从安全性和管理方式的角度看，信任容器图像是贯穿整个软件开发生命周期的关键考量。确保图像的签署和来源于一个可信的注册处是保障安全的最佳做法。不过，坚持这些做法并不足以应对审批和验证代码的核心挑战。

在容器环境中，图像被不断地加入到企业的私人注册处和枢纽，容器负责图像的收入和输出。即使列出了图像的漏洞，基于对其公司安全事件和政策的考量，开发团队也很少能提出解决办法。例如，开发人员从一个注册处中选取了一个有1000处漏洞的图像。这个数字本身的上下波动并没有可操作性。有多少诸如此类的漏洞发生呢？为什么？

放大开放源图像的问题相对容易，特别是有多个图层的图像尤其容易。为加速资源配置在图像中创建越多的图层，软件组件就会面临越大的风险，包括开放源组件。风险会在不被扫描、验证或修补的情况下产生。

我们已将发现，由于企业没有一个系统的容器漏洞评估体系，导致容器化措施施行受阻甚至搁浅。因此，一个不断改进的漏洞评估和修复体系要作为完整的一部分被纳入企业的IT风险和治理计划中去。

2.减少容器的攻击面

减少攻击面是保障安全性的基本原则。防止代码漏洞进入环境是减少一个关键攻击面的完美示例，需要注意的是，容器化有特定结构和操作要素。主要是，除了要保障主机的安全性，更要保障容器中潜在的共享内核架构的安全性；这需要维护标准配置和容器配置文件。

不像在虚拟化环境中，虚拟机管理程序作为其控制点，任何用户或服务访问内核根账户能够查看和访问所有所有容器共享Linux内核。安全团队可以依靠验证的方法来强化内核和主机，但这离用成熟和可复验的方式来确保特定于容器环境中操作过程的安全还差得很远。

其中的很多过程是容器化中固有的。例如，容器本身依靠内核以及一系列服务利用Docker防护程序通过系统调用。而Docker在调用开箱seccomp（安全计算模式）配置文件的能力有了显著提高，这些文件只在默认情况下禁用52系统调用，出于X64计算机中的313可用性，仍留下了一些开放的260系统调用。

另一个例子是把Docker防护程序绑定到Unix Docker访问组或TCP端口从而允许容器互相交流，此外，也有提供给所用用户根权限的作用。根开放可以减少运营摩擦，但是可能会使安全部门对违反最小特权访问原则表示不满。

解决隔离和容器通讯、操作和开发之间的内在张力意味着所采取的措施既要控制容器内部相互影响的程度，也要限制通过插孔或开放的端口进入到Docker 群组的容器的数量。

3.加强用户访问控制

直到最近，根在默认情况下访问Docker主机是一个非此即彼的命题，使安全专员对此十分焦虑。虽然限制访问容器主机根账户花费了他们大量的精力——并且推动了Docker在系统中删除特权访问这一新功能的投资——对安全更广泛的关注是对特权账户的强制访问控制和部署管道的操作运行。显而易见，扩大创建实用有效的访问控制规模很有益处：可以保证问责性和操作一致性。

问责需要一定的能力以便查明是什么改变了容器的设置或配置或下载图像或在生产中创建了一个容器。拥有通用的根访问权限之后，要确定是什么做出了改变几乎是不可能的。即使根访问可能是开发人员在工作过程中所需要的最简单的一种访问方式，这也意味着他们有太多的访问权限。此外，得到访问根账户权限的攻击者就相当于得到了任意访问容器的权限，包括其数据和程序。

应用集中管理约束条例使用户可以基于自己的角色做出更改或命令，而不是他们访问根账户的能力，使企业能够定义和执行标准流程。实现职责分离访问和基于用户角色的命令约束条例是确保通过软件开发生命周期的基础。

如果不采取集中的方式，很难确定每个容器中不同的用户和其对应的不同的特权是否合适，与其职能作用和最小访问特权是否一致。

4.硬化主机

容器化最重要的好处之一就是它独立于应用程序，可以在任何地方独立运行而不依赖于任何自给系统。

一个重要的意义是有了专门的工具来限制哪些是自给系统可以访问和使用的，哪些是不可以访问和使用的。对照组和命名空间是关键容器的隔离元件。对照组决定一个容器可以使用多少共享内核和系统资源。命名空间决定了一个容器可以“查看”或有效确定容器被授权访问哪些资源。这些组件的设计目标非常明确：无论你想在哪个服务器中运行多种服务，这些服务彼此尽可能相互隔离，这是确保安全性和稳定性至关重要的一点。

严苛的细节确保了对照组和命名空间中配置的恰当性和一致性，并且保证了配置和安全政策相符。

尽管对照组和命名空间隔离可以用来限制对容器中内核资源的访问，但它并不能有效地隔离容器的执行路径。资源隔离对检测和预防滥用特权或打破容器中的“箱”等扩大化攻击无效。

在运行防御和容器分析过程中缺少分层法来保证对其的有效控制和可见性，由于配置错误或攻击者采取明确的行动操控命名空间，容器的安全性很容易就被破坏了。例如，容器环境下拒绝服务攻击与“流氓”容器消耗更多的内核资源和挤占其他过程并无二致。

5.容器安全过程的自动化

在安全性领域，将安全的理念落实到实际操作中去——而且不仅仅是随后在书面上描摹它——像是一个遥不可及的梦想。尽管在DeVops和安全团队中存在着一些领域或文化分歧，将安全渗透到容器的创建、传送和运行的过程中毫无疑问是企业最感兴趣的。这不仅会使内部应用程序更加安全，也会调动DeVops和安全团队的积极性，培养更具协作性的文化。

由于安全团队往往没有意识到导致容器在生产中运行的过程，重要的是要涉及到他们工作流程的定义和促进知识的转化。因此，他们可以给适当的控制和实践提供指导原则以满足其安全标准和审计要求。

换句话说，DeVops应该做它们最擅长的事情：自动化。基于容器的应用程序开发过程已经实现高度自动化。使用CI/CD和业务流程工具是在容器的整个生命周期中保障安全的最佳实践，这使建立安全管理框架的过程变得透明和相对安全简单。它将建立一个高度安全基线，减少了对后续安全工作的需要，也降低了安全成为部署障碍的可能性。

我们都知道当安全不是优先级时发生了什么，所以除了回滚以外还有什么其他的选择吗？容器为正确地解决这一问题提供了一个很好的机会，因为他们已经完全实现了自动化。将安全过程自动化到可操作的工作流程中可能是一个新的安全措施，但是这并不是第一次在容器中出现，其自动化已经成为所有方面的业务（网络、存储等）的规范。安全仅仅成为另一种满足自动化的要求。

DeVops规定在应用程序的整个生命周期中采用自动化和协作精神来加快灵活开发速度以实现目标。安全性——是目前为止在生产过程中最必不可少的——可以使用相同的方法来达到与其相左的结果。

安全专业人员面临的最大挑战：他们可能不清楚容器部署计划，甚至在其实施过程中也不了解。安全团队的参与宜早不宜迟-DeVops操作过程——而不是等到用生产压力和生产过程延迟取代提高效率。在此之前我们看到过那种场景；没有人想看第二次。

本文由中国IDC圈独家编译，未经允许谢绝转载。