注意事项 佩雷夫 ：原始文章由瑞典工程师Christian Abdelmassih撰写，他热衷于企业级体系结构，IT安全和云计算。 最近，他获得了计算机科学的硕士学位，并且急于分享他的工作-硕士学位论文，或者是其中的一部分，致力于隔离容器化（并在Kubernetes中启动）应用程序的问题。 作为准备进行这项研究工作的“委托人”，其行为不少于其祖国的警察。
近年来，容器编排和云原生计算已变得非常流行。 它们的适应程度已经达到了使金融企业，银行和公共部门都对它们感兴趣的程度。 与其他公司相比，它们在信息安全和IT领域具有广泛的要求。
重要方面之一是如何在生产环境中使用容器，同时可以保持应用程序之间的系统隔离。 由于此类组织在裸机之上使用基于虚拟化的私有云环境，因此，在迁移到具有编排好的容器的环境时失去这种隔离是不可接受的。 考虑到这些限制，我写了论文，瑞典警察被认为是目标客户。
本文考虑的具体研究问题是：
与在裸机上运行的ESXi虚拟机管理程序之上运行的虚拟机相比，在Docker和Kubernetes中如何支持应用程序划分？
这个问题需要仔细研究。 首先，看一下共同点-应用程序。
Web应用程序令人困惑
Web应用程序中的漏洞-真正的攻击媒介动物园。 OWASP Top 10（
2013年 ，
2017年 ）介绍了其中最重大的风险。 这些资源有助于教育开发人员降低典型风险。 但是，即使开发人员编写了完美无瑕的代码，应用程序仍然可能容易受到攻击-例如，通过程序包依赖关系。
大卫·吉尔伯森（David Gilbertson）撰写了一个
很棒的故事，讲述如何通过恶意软件包注入代码，例如，该软件包作为基于Node.js的应用程序的NPM的一部分。 要检测漏洞，可以使用依赖项扫描程序，但它们只能
降低风险，而不能完全消除风险。
即使您创建的应用程序没有第三方依赖关系，相信应用程序永远不会变得容易受攻击仍然是不现实的。
由于存在这些风险，我们不能说Web应用程序是安全的。相反，请坚持
纵深防御 （DID）策略。 让我们来看看下一个层次：容器和虚拟机。
容器与虚拟机-隔离的故事
容器是一个隔离的用户空间环境，通常使用内核的功能来实现。 例如，
Docker为此使用Linux命名空间，cgroup和功能。 从这个意义上讲，Docker容器的隔离与类型1虚拟机管理程序
（即直接在硬件上工作的裸机虚拟机管理程序）启动的虚拟机有
很大不同 。
例如，可以通过
Intel VT在真正的硬件中以较低的级别实现对此类虚拟机的区分。 Docker容器又依赖Linux内核进行划分。 在进行
层以下攻击时，要考虑这一差异非常重要。
如果攻击者能够在虚拟机或容器中执行代码，则可以通过执行
逃避攻击将其降低到较低的级别。
根据在硬件上使用的是容器还是虚拟机，区分是在不同级别的基础结构上实现的。在Pwn2Own 2017黑客大赛以及GeekPwn2018期间，
VMware ESXi虚拟机管理程序已证明了此类攻击的可能性。 结果是一对
CVE （
CVE-2017–4902 ，
CVE-2018–6981 ）可用于以下层攻击以
退出虚拟机 （ 虚拟机逸出 ） 。 铁服务器上的虚拟机即使使用技术来区分铁级别，也不能保证绝对的安全性。
另一方面，如果我们查看裸机虚拟机管理程序与Linux内核之间的攻击向量，则很明显，后者具有更大的攻击面-因为其[Linux内核]大小和功能范围。 更大的攻击面意味着使用容器隔离为云环境提供更多潜在的攻击媒介。 这体现在对
容器转义攻击的日益关注，这要归功于内核漏洞利用（例如
CVE-2016-5195 [即Dirty COW- 大约翻译] ，
CVE-2017–1000405 ）
诸如
SELinux或
AppArmor之类的模块可用于提高容器
内部的绝缘性。 不幸的是，内核中的这种安全机制不能防止对内核本身的逃脱攻击。 如果无法超越限制，它们只会限制攻击者可能采取的行动。 如果我们要处理容器外部的出口，
则需要容器
外部甚至核心的隔离机制。 例如，沙箱
（sandbox） ！
gVisor是容器
运行时的沙箱，其代码由Google打开，并在容器和OS内核之间添加了一个附加内核。 这种类型的沙箱可以通过
在内核级别发生越界容器攻击来改善这种情况。 但是，核心漏洞利用只是攻击者的工具之一。
要查看其他攻击如何导致相似的结果，您需要查看有关在云原生时代如何使用容器的更一般的描述。
容器编排对隔离的影响
为了管理在具有多个节点的环境中运行的容器，他们引入了编排，其中Kubernetes发挥了主导作用。 事实证明，协调器错误也可能影响容器隔离。
蒂姆·阿克莱尔（Tim Allclair）在KubeCon 2018上
做了精彩的演讲，他指出了一些攻击面。 他在报告中
提到了一个示例（
CVE-2017-1002101 ），编排错误如何影响隔离-在这种情况下，通过在pod外部安装磁盘空间的能力。 这种漏洞非常成问题，因为 可以绕过包装容器的沙箱。
通过引入Kubernetes，我们扩大了攻击面。 它包括Kubernetes主服务器上托管的系统。 其中之一是Kubernetes API服务器，他们最近在该服务器中发现了一个漏洞，该漏洞可能允许
过多的特权（
CVE-2018-1002105 ）。 由于Kubernetes管理员的攻击面不在我的研究范围之内，因此不考虑此特定漏洞。
为什么逃脱攻击如此重要？ 容器提供了在同一OS中运行许多共同托管的应用程序的能力。 因此存在与应用程序隔离相关的风险。 如果关键业务应用程序和另一个易受攻击的应用程序在同一主机上运行，则攻击者可以通过对易受攻击的应用程序的攻击来获得对关键应用程序的访问。
根据组织使用的是哪种数据，其泄漏不仅会损害组织本身，还会损害个人和整个国家。 您还记得，我们谈论的是公共部门，金融，银行……-泄漏会严重影响人们的生活。
那么容器编排甚至可以在这样的环境中使用吗？ 在开始进一步思考之前，必须进行风险评估。
什么风险可以接受？
在引入安全措施之前，重要的是考虑组织实际上试图保护的信息类型。 是否需要采取进一步措施来防止对容器进行可能的越狱攻击的决定取决于组织所使用的数据及其提供的服务。
从长远来看，这意味着为了实现在受容器沙箱保护的，
配置正确的主机上退出容器的可能性，攻击者必须：
- 例如通过代码注入或使用应用程序代码中的漏洞在容器中执行代码；
- 利用另一个零日漏洞，或者即使存在沙箱，也尚未应用补丁程序退出容器的漏洞。
您可能会猜到，认为这种情况不可接受的组织应该使用对
机密性 ，
完整性和/或
可访问性要求非常高的数据或提供服务。
由于本文仅针对此类客户端，因此不允许由于走出容器而丢失系统隔离性，因为 它的后果太重大了。 可以采取哪些步骤来改善隔离度？ 要提升隔离阶梯的水平，您还应该查看包装OS内核的沙箱，即 虚拟机！
使用托管虚拟机管理程序的虚拟化技术将改善这种情况，但我们希望进一步限制攻击面。 因此，让我们检查一下安装在熨斗上的虚拟机管理程序，看看它们将带给我们什么。
铁上的管理程序
瑞典瑞典国防研究局的一项
研究检查了与瑞典武装部队有关的虚拟化风险。 他的结论谈到了这些技术对军方的好处，即使严格的安全要求和虚拟化带来的风险也是如此。
在这方面，我们可以说虚拟化（在一定程度上）用于国防工业，因为它具有
可接受的风险 。 由于国防工业中的机构和企业是对IT安全性要求最高的客户之一，因此我们也可以认为，可接受的风险意味着本文所考虑的客户可以接受。 所有这一切-尽管潜在的问题超出了虚拟机，如上所述。
如果我们决定将这种类型的沙箱用于容器，则在云原生特性的上下文中需要考虑一些事项。
虚拟机的沙箱节点
这个想法是Kubernetes集群的节点是使用硬件虚拟化的虚拟机。 由于虚拟机将对在Pod中运行的容器扮演沙箱的角色，因此每个节点都可以视为受沙箱保护的环境。
在已经提到的容器沙箱的上下文中，关于这些沙箱的重要说明：这种方法允许您将多个容器放入一个沙箱中。 与每个容器都有自己的沙箱的情况相比，这种灵活性可以减少开销。 由于每个沙盒都具有自己的操作系统，因此我们希望在保持隔离的同时减少其数量。
安装在硬件（群集节点）上的虚拟机充当容器的沙箱。 在不同VM中运行的容器具有可接受的风险级别。 但是，这不适用于在同一VM上运行的容器。但是，由于Kubernetes能够出于各种原因更改Pod的位置，这可能会
破坏使用沙箱的想法 ，因此有必要在共享Pod的机制上增加限制。 您可以通过多种方式实现期望。
在撰写本文时，Kubernetes（
v1.13 ）支持三种主要方法来控制Pod的计划和/或启动：
使用哪种方法取决于组织的应用程序。 但是，重要的是要注意，方法进入执行阶段后，它们丢弃Pod的能力有所不同。 现在，只有污点才能做到这一点-通过NoExecute动作。 如果您不以任何方式处理此刻，并且某些标签发生变化，那么一切都会导致不良的共址。
符合托管要求
本文提出了使用分类系统的思想，该分类系统显示了如何在共址中反映出敏感性。 想法是使用容器与容器之间的1：1关系，并根据容器化应用程序的分类确定容器的共置位置。
为了简单和可重用，使用了以下三步分类系统：
- O级 ：应用程序不敏感，没有隔离要求。 可以将其放置在不属于其他类的任何节点上。
- PG类 （私有组） ：一个应用程序和一组其他应用程序一起形成一个私有组，为此需要一个专用节点。 应用程序只能托管在具有相应私有组标识符的PG类节点上。
- P类 （私有） ：应用程序需要一个单独的私有节点，并且只能放置在其类（P）的空节点上。
为了满足许多分类应用程序在同一位置的要求，使用了污点和容差，为每个节点分配了一个类别，使用PodAffinity对P类或PG类应用程序的Pod施加了附加限制。
这个简化的示例显示了如何使用污点和公差来实施共置位控制：
Pod 2和Pod 3包含来自一个私有组的应用程序，而Pod 1上的应用程序更敏感，需要一个专用节点。但是，P和PG类将需要其他关联性规则，以确保随着群集和托管应用程序的增长，执行分界请求。 让我们看看如何为不同的类实现
这些规则 ：
# Class P affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: "kubernetes.io/hostname" namespaces: ["default"] labelSelector: matchExpressions: - key: non-existing-key operator: DoesNotExist
P类应用程序的相似性规则需要专用节点。 在这种情况下，如果在没有
non-existing-key情况下退出广告连播，则不会安排该广告连播。 一切正常，直到单个吊舱拥有此钥匙。
# Class PG affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: "kubernetes.io/hostname" labelSelector: matchLabels: class-pg-group-1: foobar podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: "kubernetes.io/hostname" labelSelector: matchExpressions: - key: class-pg-group-1 operator: DoesNotExist
对于PG类应用程序，“相似性”规则将共同托管具有
class-pg-group-1组标识符的Pod，并共同托管具有Pod而没有标识符的节点。
这种方法将允许我们使用分类系统根据容器化应用程序的相关要求对容器进行定界。
我们得到了什么？
结论
我们考虑了一种基于类型1虚拟机管理程序（即在裸机上启动）来实现沙箱的方法，以在Kubernetes集群中创建节点，并提出了一种分类系统，该系统定义了界定容器化应用程序的要求。 如果我们将此方法与考虑的其他解决方案进行比较，则在确保系统隔离方面具有优势。
一个重要的结论是，隔离策略
限制了逃脱攻击向容器
的传播 。
换句话说，不能防止离开容器本身，但是可以减轻其影响。 显然，随之而来的是进行类似比较时必须考虑的其他困难。
为了在云环境中使用指定的方法并提供可伸缩性，将对自动化提出其他要求。 例如，自动化虚拟机的创建及其在Kubernetes集群中的使用。 最重要的是将实现和验证
广泛的应用程序分类。
这是我关于
隔离容器化应用程序的论文的一部分。
为了防止攻击者从一个节点上退出容器攻击其他节点的服务的可能性，有必要考虑
网络传播的攻击 。 考虑到这些风险，我的论文提出
了集群网络的分段并介绍了云架构，其中一种具有
硬件防火墙 。
那些
感兴趣的人可以阅读完整的文档-论文的文本可公开获取：“
瑞典警察局在严苛的安全环境中进行容器编排 ”。
译者的PS
另请参阅我们的博客：