2020年4月,微软官方发布了《Kubernetes威胁矩阵》第一版,首次尝试以系统方式描绘Kubernetes威胁态势。该报告采用了MITER ATT&CK®框架结构,希望与行业标准尽可能保持一致。

编者注:Kubernetes是由Google在2014年开源的容器集群管理平台,用于管理容器化环境中的工作负载和服务。

自去年的威胁矩阵报告发布以来,情况发生了如下变化:

  • Kubernetes工作负载吸引到更多攻击者的注意,新的威胁也由此而生;

  • 安全社区采纳了该矩阵,并添加更多安全保障技术;

  • 随着Kubernetes的发展,其默认安全性得到显著提升,因此上份报告中的某些方法已经不再适用。

3月23日,微软安全发布了《Kubernetes威胁矩阵》第二版,将上述变化纳入其中。第二版报告添加了微软研究人员发现的新方法与社区解决方案,并淘汰了部分过时内容,因为其不再适用于Kubernetes的较新版本。报告还添加了“数据收集”这一新增单元。

淘汰了哪些内容?

Kubernetes一直快速发展,默认安全水平也在持续提升。去年矩阵中出现的某些技术已经不适用于较新环境,因此我们决定淘汰以下内容:

1、Kubernetes仪表板暴露

Kubernetes仪表板的使用率近来有所下降。各类云托管集群(包括微软AKS与谷歌GKE)纷纷弃用这项服务,转而通过门户内的集中界面提供等效功能。此外,最新版本的Kubernetes仪表板已经要求身份验证,因此这种意外暴露的风险已经显著降低。同理,我们还取消了横向移动策略下的“访问Kubernetes仪表板”部分。但请注意,Kubernetes的较旧版本(包括手动安装仪表板的较新集群)仍会受到这类问题的影响。为了体现最新情况,我们将此问题的概念汇总到新的“敏感界面暴露”部分(详见下文)。

2、Tiller被访问

从版本3开始,Helm不再使用其服务器端组件Tiller。这是一项重要安全改进,因此现在Helm在默认情况下将使用kubeconfig文件中的用户凭证执行操作。但使用较旧版本的Helm用户仍会受到此问题的影响。

威胁矩阵中的新内容

1.、初始访问

  • 敏感接口暴露

将敏感接口直接暴露在互联网下当然会引发安全风险。某些流行框架在设计上也没有考虑到直接暴露于互联网中的情况,因此默认并不要求身份验证。一旦开放其中的敏感接口,攻击者很可能以未授权方式访问敏感接口,进而在集群当中运行代码或部署容器。目前,已经发现的此类敏感接口包括Apache NiFi、Kubeflow、Argo Workflows、Weave Scope以及Kubernetes仪表板。

2.、代码执行

  • Sidecar注入

Kubernetes Pod是一组共享存储与网络资源的单一或多个容器。Sidecar容器是专用术语,代表与主容器并排放置的其他容器。例如,服务网格(service-mesh)代理在应用程序的Pod中充当Sidecar。攻击者可以将Sidecar容器注入至集群内的合法Pod,借此运行代码并隐藏行迹。相较于在集群中运行独立Pod,这种方法无疑更难被发现。

3、持久驻留

  • 恶意准入控制器

准入控制器(admission controller)是Kubernetes提供的组件,负责拦截并修改指向Kubernetes API服务器的请求。准入控制器分为两种类型:验证控制器与变异控制器。顾名思义,变异准入控制器能够修改拦截到的请求并更改其属性。Kubernetes还提供名为MutatingAdmissionWebhook的内置通用准入控制器,其行为由用户在集群中部署的准入webhook决定。攻击者可以使用此类webhook持久驻留在集群当中。例如,攻击者可以拦截并修改集群内的Pod创建操作,借此向所有新创建的Pod添加恶意容器。

4、凭证访问

  • 访问托管身份凭证

托管身份,是指由云服务商负责托管的身份,我们可以将其分配给虚拟机等多种云资源。这些身份用于对云服务进行身份验证。身份secret信息由云服务商全面托管,确保用户无需因凭证管理而分神。应用程序则访问实例元数据服务(IMDS)以获取身份令牌。一旦获得对Kubernetes Pod的访问权,攻击者就可以利用指向IMDS端点的访问权限获取托管身份令牌,进而访问各类云资源。

  • 恶意准入控制器

除了持久驻留之外,恶意准入控制器还可用于访问凭证信息。Kubernetes提供内置准入控制器ValidatingAdmissionWebhook。与MutatingAdmissionWebhook类似,这种准入控制器同样具有通用性且具体行为由部署在集群中的准入Webhook决定。攻击者可以使用此Webhook拦截指向API服务器的请求,借此记录secret信息及其他敏感信息。

5.、横向移动

  • CoreDNS污染

CordDNS是由Go语言编写而成的模块化域名系统(DNS)服务器,目前由云原生计算基金会(CNCF)负责管理。CoreDNS也是Kubernetes中使用的主要DNS服务。用户可以通过corefile文件修改CoreDNS的具体配置。在Kubernetes中,此文件存储在ConfigMap对象当中,此对象又位于kube-system命名空间内。如果攻击者具有修改ConfigMap的权限(例如通过使用容器的服务账户),即可更改集群的DNS行为、实现DNS污染并夺取其他服务的网络身份。

  • ARP污染与IP欺诈

Kubernetes提供多种可在集群内使用的网络插件(被称为容器网络接口,简称CNI),并在多数场景下默认使用。在这类配置中,各个节点(cbr0)上都创建有一个网桥,且不同节点使用veth接入其他节点。跨Pod流量将通过网桥(2级组件)传输,意味着攻击者完全可以在集群当中执行ARP污染。一旦攻击者成功访问到集群内的某一Pod,即可执行ARP污染并对其他Pod进行流量欺诈。如此一来,攻击者即可实现横向转移,例如实施DNS欺诈或窃取其他Pod的云身份(CVE-2021-1677)。

6.、数据收集

在本次更新中,我们还在报告中新增了“数据收集”策略。在Kubernetes中,数据收集是指攻击者从集群处或者经由集群进行数据收集的方法。

  • 来自私有注册表的镜像

集群中运行的镜像可以被存储在私有注册表内。要提取这些镜像,容器运行时引擎(Docker或者containerd)需要具备指向这些注册表的有效凭证。如果注册表由云服务商负责托管,则在Azure容器注册表(ACR)或者Amazon弹性容器注册表(ECR)等服务中,我们需要使用云凭证在注册表上完成身份验证。一旦攻击者能够访问到集群,则有可能顺利访问私有注册表并从中提取镜像。例如,攻击者可以按照“访问托管身份凭证”部分中提到的方式使用托管身份令牌。同样,在EKS中,攻击者也可以使用默认绑定至节点IAM角色的AmazonEC2ContainerRegistryReadOnly策略。

保护您的容器化环境

要为容器化环境构建行之有效的安全解决方案,我们首先需要迈出了解容器化环境这重要的第一步。希望此次修订后的《Kubernetes威胁矩阵》报告能够帮助大家发现针对Kubernetes的各类威胁行为,厘清实际防御能力与当前威胁形势之间的实际差距。

原文链接:

https://www.microsoft.com/security/blog/2021/03/23/secure-containerized-environments-with-updated-threat-matrix-for-kubernetes/

声明:本文来自互联网士冗科技,版权归作者所有。文章内容仅代表作者独立观点,不代表士冗科技立场,转载目的在于传递更多信息。如有侵权,请联系 service@expshell.com。