在本节课程中,我们将学习一个K8s攻击案例,高权限Service Account接管集群。如果攻击者获取到有效的凭证,就有可能通过凭证来接管整个K8s集群。
在这个课程中,我们将学习以下内容:
-
K8s的认证方式:介绍两种比较常见的身份认证方式,UserAccount和ServiceAccount。
-
K8s身份认证攻击案例:深入分析具体的攻击细节,了解攻击者是如何获取凭证并利用凭证来接管集群的。
首先,我们来介绍一下K8s的认证方式。在K8s集群环境中,为了确保集群的安全性,K8s提供了两种比较常见的身份认证方式,来对访问集群内资源的用户进行认证,以确保只有授权的用户可以访问集群内的资源。
基于K8s的这两种身份认证方式:
攻击者可能会尝试获取有效的Service account凭证,并利用这些凭据来访问集群中的敏感资源,执行特权操作,甚至在集群中创建、修改或删除资源。
另外,攻击者还可以尝试获取集群管理员的Kubeconfig文件,一旦攻击者获取了kubeconfig文件,意味着攻击者可以直接使用配置文件中包含的凭据和访问权限来连接和控制集群。
我们梳理了一张攻击路径图,如图所示:
假设攻击者成功入侵了一个容器内的web应用,并获得了这个Pod的shell权限,这个时候,如果Pod关联的Service Account拥有创建Pod的权限,攻击者就可以利用污点容忍的方式,将一个恶意Pod调度到Master节点上,通过在恶意Pod中挂载根目录,攻击者就可以获取到Master节点上的 kubeconfig 文件,从而直接接管整个K8s集群。
在这张攻击路径图里:
攻击者入侵容器应用拿到shell权限,进一步通过容器逃逸拿下了Node节点权限,在Node节点上尝试搜索kubeconfig文件或是尝试在运行的pod里面找到高权限的Service Account,使用窃取的凭证与API Server进行交互,通过污点容忍创建恶意pod,从而获取集群权限。
云原生安全攻防--K8s攻击案例:高权限Service Account接管集群