例如通过代码注入或使用应用程序代码中的现有漏洞来执行容器中的代码;
尽管存在容器沙盒,但是可以利用另一个0day或者未修补的漏洞实现容器逃逸。
你懂的,对于上述这些场景,从事数据处理或者是提供对 机密性, 完整性以及/或者是 可用性方面要求很高的服务的企业断然是无法接受的。 笔者论文是将这些客户的情况考虑在内的,而容器逃逸造成的系统隔离性的损失显然是无法接受的,因为这样造成的后果非常严重。那么,我们可以采取哪些措施来进一步地提高容器的系统隔离性呢?想要在隔离性上面迈出一步的话,我们不妨考虑一下包装了操作系统内核的沙盒 - 虚拟机! 尽管利用受托管的hypervisor的虚拟化技术可以带来一些提升,但是我们希望能够进一步限制攻击面。因此,让我们利用一下裸金属hypervisor,看看他们能够为我们带来什么。 裸金属hypervisor 在瑞典国防研究局发布的一份报告[11]中,他们对瑞典武装部队使用虚拟化技术的风险进行了评估。报告的结论是,尽管安全性方面存在一些苛刻要求,而且虚拟化可能会带来一些潜在的风险,但是对于武装部队而言引入虚拟化技术仍然是有用的。 在这方面,我们不妨假定我们在国防工业中(在某种程度上)已经使用了虚拟化技术,因为它带来的风险是 可以接受的。由于国防工业中的代理商和企业是IT安全领域里要求最苛刻的客户之一,我们也可以说,对他们来说可接受的风险,也是本论文范畴内的其他客户可以接受的。我们之前也讨论过虚拟机逃逸的可能性,它其实也是这样。 如果我们决定将容器搭配这种类型的沙盒一起使用的话,我们还需要将一些因素考虑在内,让它变得更具备云原生的特性。 虚拟机沙盒节点 我们的想法是采用裸金属虚拟化的虚拟机作为Kubernetes集群的节点。由于虚拟机将充当在pod中运行的容器的沙盒,因此我们可以将每个节点看作一个沙盒环境。 这种类型的沙盒与前面提到的容器沙盒之间的一个重要关注点在于,这种方案允许将多个容器放在同一个沙盒里。和每个容器都有自己的沙盒相比,这种灵活的实现方式减少了一些性能开销,由于每个沙盒都带有自己的操作系统,我们希望在保持隔离性的同时尽量减少沙盒的数量。 图2 裸金属虚拟机节点充当容器的沙盒。在不同的虚拟机中运行的容器之间系统隔离方面的风险是可以接受的。然而,在同一台虚拟机中运行的容器则不是。 然而,由于 Kubernetes 可能出于种种原因将pod重新调度到其他节点上,这可能会破坏沙盒,我们需要对pod调度寻址机制添加一些限制。这一点可以通过多种方式实现。 截至本文撰写时,Kubernetes(v1.13)支持3种主要方法来控制Pod的调度和/或执行。NodeSelector & NodeAffinity
Taints & Tolerations
PodAffinity & PodAntiAffinity
使用哪(几)种方法取决于企业的应用程序类型。但是,要注意的一点是,上述方案在进入 pod 执行阶段后拒绝调度 pod 的能力各不相同。目前只有taints能够通过 NoExecute操作实现这一点。如果该请求没有处理并且某些标签发生了更改,那么可能会导致预期之外的重新调度寻址。 表达共址需求 笔者在论文中提出了如何使用分类系统将应用的敏感程度映射到寻址方式上的实现。我们的想法是将容器和Pod进行一对一关联,并且让共址运行的Pod调度基于容器化应用程序的分类实现。 出于简单性和复用性的设计考虑,我们通过以下3个步骤进行系统的分类。O类:应用程序不敏感,对隔离性方面没有要求。它可以在任何不属于其他类的节点上进行调度。
PG类:该应用程序与一组其他应用程序一起形成一个私有组,并且该组需要一个专属节点。因此,应用程序只能调度到带有对应私有组标识符的PG类节点上。
P类:应用程序需要私有和专属节点,并且只能在P类的空节点上进行调度。
为了满足同一组分类的应用程序的共址需求,我们可以使用taint和toleration给每个节点标记一个分类,然后使用PodAffinity对包含P或PG类应用程序的Pod增加额外限制。 这个简化的例子展示了如何使用taint和toleration来实现共址控制。视频 Pod 2和3包含来自同一个私有组的应用程序,而Pod 4中的应用程序更敏感并且需要专属节点
但是,对于P类和PG类应用程序而言,我们需要给它们设置额外的Affinity规则以确保在集群及其托管的应用程序增长的同时仍然满足隔离需求。让我们看看我们如何为不同的分类实现关联规则: P类应用程序的Affinity规则需要专属节点。在这种情况下,如果没有 non-existing-key的话不会调度pod。如果没有pod有这个key的话它会一直尝试下去。# Class P
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- topologyKey: "kubernetes.io/hostname"
namespaces: ["default"]
labelSelector:
matchExpressions:
- key: non-existing-key
operator: DoesNotExist
对于PG类应用程序,关联规则将和具有组标识符 class-pg-group-1的pod和没有标识符的pod的节点共同寻址。# 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
这使得我们可以通过基于分类的系统,根据容器化应用程序的隔离需求来分离容器。 那么这又为我们带来了什么呢? 小结 在本文中,我们介绍了一种强制使用基于裸金属hypervisior的沙盒技术来创建Kubernetes集群节点的方案,并且引入了一个分类系统来表达容器化应用程序的隔离需求。同我们在系统隔离方面讨论的其他解决方案相比,这个方案有一些优势。 它的一个重要卖点就是隔离策略可以限制容器逃逸攻击的传播。换句话说—— 容器逃逸本身并没有减轻,但是因此可能造成的后果得到了缓解。显然,这带来了更多的复杂性,需要多加权衡考虑。 另外,为了以可扩展的方式在云中使用它,它还必须额外满足自动化的一些需求。例如,自动创建虚拟机,将它们添加到Kubernetes集群。最重要的是,我们还必须实现并验证应用程序分类机制 始终如期望的那样运行。 以上几乎包含了我的论文中涉及 容器化应用程序隔离的部分。 然而,为了防止在一个节点上实现容器逃逸的攻击者攻击其他节点上的服务,我们需要考虑 网络传播攻击。为了尝试化解这些风险,笔者的论文里进一步提出了 集群网络分段的方案,并且给出了一些云架构,其中一个功能就是用到 硬件防火墙。 限于篇幅,你可以阅读笔者的论文了解更多详情,Container Orchestration in Security Demanding Environments at the Swedish Police Authority[12]。 码的开心! 相关链接:https://www.owasp.org/index.php/Top102013
https://www.owasp.org/index.php/Category:OWASPTopTen2017Project
https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5
https://searchsecurity.techtarget.com/definition/defense-in-depth
https://nvd.nist.gov/vuln/detail/CVE-2017-4902
https://www.vmware.com/security/advisories/VMSA-2018-0027.html
https://nvd.nist.gov/vuln/detail/CVE-2016-5195
https://nvd.nist.gov/vuln/detail/CVE-2017-1000405
https://nvd.nist.gov/vuln/detail/CVE-2017-1002101
https://access.redhat.com/security/cve/cve-2018-1002105
https://www.foi.se/en/foi/news-and-pressroom/news/2017-12-04-virtualized-it-systems-require-risk-assessment.html
http://kth.diva-portal.org/smash/record.jsf?pid=diva2:1231856
原文链接:https://medium.com/@chrismessiah/docker-and-kubernetes-in-high-security-environments-d851645e8b99 Kubernetes入门与进阶实战培训 Kubernetes入门与进阶实战培训将于2019年6月14日在北京开课,3天时间带你系统掌握Kubernetes,学习效果不好可以继续学习。本次培训包括:Docker基础、容器技术、Docker镜像、数据共享与持久化、Docker三驾马车、Docker实践、Kubernetes基础、Pod基础与进阶、常用对象操作、服务发现、Helm、Kubernetes核心组件原理分析、Kubernetes服务质量保证、调度详解与应用场景、网络、基于Kubernetes的CI/CD、基于Kubernetes的配置管理等,点击下方图片或者点击阅读原文了解详情。