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/
声明：本文来自互联网安全内参，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
版权归原作者所有，如若转载，请注明出处：https://www.ciocso.com/article/652.html
