2024年RSA大会上，来自Google的安全工程师Lenin Alevski和Semgrep[1]安全研究员Max vonBlankenburg的议题 Kubernetes Security Attacking And Defending Modern Infrastructure [3]从Kubernetes安全矩阵的各个阶段出发，向观众介绍了容器和容器编排工具的基本概念和组件功能，并详细介绍了Kubernetes的威胁模型，以及由OWASP提出的OWASP Kubernetes Risks Top 10[2]风险清单。Max vonBlankenburg和Lenin Alevski在此次演讲中重点分享了一些常见的Kubernetes安全攻击手法，并提出了相应的防御措施以及对Kubernetes未来趋势进行了分析。
一、背景信息
云原生可称为云计算的下半场，近年兴起的容器和编排技术凭借其弹性敏捷的特性和活跃强大的社区支持，成为了云原生生态的重要支撑技术。容器化部署形态也在改变云端应用的设计、开发、部署和运行，从而重构云上业务模式。
容器和容器编排系统的安全风险将直接影响整个云原生系统的安全性。从IT基础设施的视角看，云原生系统底层是容器，其基于操作系统虚拟化技术，跟其他的虚拟化云计算平台一样，存在逃逸和云内横向移动的风险；上层是以微服务为中心的容器编排、服务网格、无服务器计算（Serverless Computing）等系统，其API、业务存在被攻击的风险。
此外，从DevOps的视角看，云原生系统所包含的软件供应链（如第三方软件库、容器镜像等、第三方厂商非授权发布软件仓库等）也存在被投毒或恶意攻击的风险；整个开发环节，如CI/CD，也存在被攻击的风险
二、Kubernetes威胁模型
图1 Kubernetes威胁模型示意
Max vonBlankenburg和Lenin Alevski提出了关于微软发布的Kubernetes的威胁模型，着重从攻击者的角度出发，分析了控制平面（Control Plane）和工作节点（Worker Nodes）两个攻击源的可能性。
如果攻击者控制了控制平面，他们可以对整个集群的主节点、工作节点以及其中运行的Pod和容器进行任意地访问、修改和破坏。
而如果攻击者控制了工作节点，则有以下几种可能的攻击手段：
- 利用Kubelet组件控制运行的业务容器，对其进行增删改查。
- 利用容器中应用程序的已知漏洞或目录挂载进行利用从而达到容器逃逸至宿主机的目的，容器逃逸比较知名的CVE有2016年曝出的脏牛漏洞（CVE-2016-5195）及2019年曝出的runC漏洞（CVE-2019-5736），关于容器逃逸漏洞，绿盟科技研究通讯曾发布过相关文章《云原生攻防研究 — 容器逃逸技术概览》《容器逃逸成真：从CTF解题到CVE-2019-5736漏洞挖掘分析》，感兴趣的读者可以阅读。
三、Kubernetes威胁矩阵
在他们的演讲中，安全研究人员首先介绍了微软在2020年提出的Kubernetes威胁矩阵，然后对最近一次微软在2021年提出的新版本进行了比较，使得观众能够更清楚地了解Kubernetes安全领域的发展和演变。
图2 微软在2021年提出的Kubernetes威胁矩阵
可以看出相较于旧版本，新版本有以下变化：
初始访问矩阵
废弃了“暴露的Kubernetes Dashboard”攻击面。实际上，从Kubernetes Dashboard的历史版本迭代中可以看出，在v1.10.1之前，无须配置登录即可访问，仅需在Web登录界面点击“跳过”按钮。但在v1.10.1版本后，开发团队增加了显式配置功能，需要在相应部署的yaml文件中指定–enable-skip-login参数才能开启未授权访问。而当前的Kubernetes Dashboard已经延伸至v7.4.0版本，旧版本的使用率已经大幅降低。
另外，新增了“暴露的敏感信息接口”这一攻击面。例如，许多私有化部署的容器编排平台，如Openshift、Rancher、VMware Tanzu等，都提供了敏感信息接口。攻击者可以利用这些接口的不安全配置对平台进行未授权访问。
执行矩阵
新增了“边车容器注入”的攻击面。最初，边车容器实际上是作为辅助容器与主业务容器在同一Pod中运行，以此来增强或扩展主应用容器的功能，而无须直接修改主应用代码。然而，近年来随着服务网格的流行（例如Envoy Sidecar模式），边车容器也常被作为一种攻击技术。主要目的是提升攻击资产的隐蔽性，使得攻击更加难以检测和防御。
获取凭证矩阵
新增了“恶意准入控制器”和“访问管理身份凭证”攻击面。特别需要注意的是“恶意准入控制器”，它实际上是一段代码，在用户请求通过认证授权之后，Kubernetes资源对象持久化之前进行拦截。集群管理员可以通过在kube-apiserver配置文件中指定“–enable-admission-plugins”参数项的值来启用准入控制器。Kubernetes包含许多准入控制器，其中常见的有MutatingAdmissionWebhook和ValidatingAdmissionWebhook准入控制器。它们分别用于拦截并修改Kubernetes API Server请求的对象以及对其对象格式进行校验。近年来，利用准入控制器修改YAML以向业务Pod中添加恶意容器的攻击面变得尤为突出。
横向移动矩阵
废弃了“Kubernetes Dashboard的访问”和“访问Tiller端点”的攻击面。访问Tiller端点的攻击面与前文提及的Kubernetes Dashboard类似，都是因为Kubernetes社区和相关厂商对Tiller的安全性问题进行了持续改进，可以通过更新和加固Tiller组件来消除这些攻击面。
新增了“CoreDNS投毒”和“ARP投毒”攻击面。CoreDNS是Kubernetes中使用的主要DNS服务。攻击者可以通过修改位于kube-system命名空间的ConfigMap中的corefile文件来更改集群DNS的行为，从而对其进行投毒，并获取其他服务的网络身份。
收集矩阵
新增了“获取私有镜像”攻击面，公有云托管的Kubernetes集群服务中，如果攻击者可以访问集群，某些情况下则可能对相应容器镜像仓库进行访问，从而对镜像进行投毒操作。
接下来，笔者将对本次议题的重点—— 常见的Kubernetes攻击技术进行介绍。
3.1 初始访问矩阵
常见的攻击技术包括利用云凭证、暴露的 Kubeconfig、受攻击的镜像仓库/镜像、利用已知漏洞、暴露的敏感接口等。
a) 利用云凭证可以访问公有云提供的 Kubernetes 服务。目前，由于安全意识不足，开发者常将云凭证硬编码到系统业务源码中，导致这些敏感信息在公网泄露。攻击者可以利用泄露的云凭证访问 Kubernetes 资产，并进行篡改、删除等恶意操作。
b) kubeconfig 与暴露的云凭证类似，只是攻击者可以通过 kubeconfig 在网络可达的情况下获取 Kubernetes 控制面的权限，从而对集群资源进行恶意操作。
图3 泄露的kubeconfig信息
c) 利用受攻击的镜像仓库，上传恶意镜像并进行投毒，引发供应链攻击。
d) 暴露的敏感接口以及已知漏洞利用同样会导致未经授权的访问和容器逃逸，从而增加横向移动的风险。
3.2 执行矩阵
本次议题中，Max vonBlankenburg和Lenin Alevski安全研究员介绍了执行矩阵的一些攻击技术，主要分为三个场景：
场景一：利用用户凭证、kubeconfig、应用RCE漏洞进行资产探测。
图4 执行矩阵-攻击场景1
如上图所示，攻击者主要通过用户凭证、kubeconfig等信息获取到Kubernetes主节点的控制权，并通过kubectl访问业务Pod执行资产探测操作，或是通过业务Pod的已知RCE漏洞在Pod内部进行命令执行操作。
场景二：利用用户凭证、kubeconfig创建恶意容器进行挖矿。
图5 执行矩阵-攻击场景2
如上图所示，攻击者主要通过用户凭证、kubeconfig等信息获取到Kubernetes主节点的控制权，并通过kubectl创建crypto miner Pod执行恶意挖矿操作。
场景三：利用用户凭证、kubeconfig在现有业务Pod上注入边车容器进行恶意操作。
图6 执行矩阵-攻击场景3
如上图所示，攻击者主要通过用户凭证、kubeconfig等信息获取到Kubernetes主节点的控制权，并通过kubectl patch在现有Pod基础上注入Sidecar容器执行恶意操作。
3.3 持久化矩阵
Max vonBlankenburg和Lenin Alevski安全研究员在持久化矩阵介绍了两种攻击场景。
场景一：利用用户凭证、kubeconfig、应用RCE漏洞在现有业务Pod中挂载Hostpath写入操作。
图7 持久化矩阵-攻击场景1
如上图所示，攻击者主要通过用户凭证、kubeconfig等信息获取到Kubernetes主节点的控制权，并通过kubectl修改业务Pod的yaml配置文件，将容器内的可写目录以Hostpath形式挂载至宿主机，从而进行持久化操作。
场景二： 通过Malicious准入控制器在现有业务Pod中注入恶意边车容器。
图8 持久化矩阵-攻击场景2
如上图所示，攻击者可通过前述的凭证和kubeconfig配置文件获取到Kubernetes主节点控制权，并通过创建Admission Controller拦截正常用户部署的工作负载请求，并在请求所属业务yaml配置文件中注入边车容器配置，从而进行持久化操作。
3.4 权限提升矩阵
场景一：部署特权容器导致权限提升
如我们所知，一旦Pod部署时指定Privleged配置为True, 则该Pod与宿主机共享PID、Network等命名空间，攻击者进而可通过共享命名空间的方式提权达到效果
场景二：绑定集群角色权限导致权限提升
若Pod所属服务账户（Service Account）绑定了Kubernetes的ClusterRole权限，同时该Pod存在RCE漏洞，则攻击者可以通过服务账户的Token操作集群资源，进而达到权限提升的效果。
3.5 防御绕过矩阵
- 清理容器日志、删除Kubernetes事件：避免日志审计进行溯源
- 利用Pod/容器名的相似性：提升攻击资产的隐秘性
- 使用代理服务连接集群：避免对访问记录进行溯源
3.6 获取凭证矩阵
- 通过kubectl列出Kubernetes的Secrets资源信息；
- 通过kubectl访问Pod服务账户（Service Account）；
- 通过部署恶意准入控制器获取凭证信息。
3.7 发现矩阵
Kubernetes的核心组件API Server和Kubelet可用于发现集群中的元数据信息，如Deployment、Pod、Service等业务资源，同时也可以通过Kubernetes Dashboard或Instance Metadata API发现更多的集群资源信息。
3.8 横向移动矩阵
- 利用应用漏洞进行容器逃逸并访问集群中的其他资源，达到横向移动的效果；
- 利用服务账户进行横向移动；
- 利用集群内部的网络进行横向移动；
- 利用集群业务应用中的凭证信息进行横向移动；
- 利用CoreDNS投毒进行横向移动。
3.9 收集矩阵
演讲者主要提到通过访问私有镜像仓库，进行镜像下载、并通过镜像投毒的方式引发供应链攻击，上文已有说明，此处不再赘述。
3.10 危害矩阵
- 攻击者可能删除PV（持久卷）、日志、事件等资源；
- 攻击者可能进行Kubernetes资源劫持；
- 攻击者可能利用上述的边车注入或创建容器的方式部署加密货币挖矿程序，进行种子下载等恶意操作；
- 攻击者在控制Kubernetes管理平面后可对Pod进行恶意操作，并部署新的恶意服务。
四、Kubernetes内部安全机制
API Server认证授权
API Server实现了Kubernetes资源增删改查的接口，因而在用户对资源进行操作之前，需要对用户进行相应地认证操作，Kubernetes支持多种认证类型，例如静态令牌文件、X.509 客户端证书、服务账号令牌、基于OAuth 2.0的OpenID Connect （OIDC）令牌、Webhook令牌身份等。
API Server授权（Authorization）
Kubernetes包含四类授权模式，分别为节点（Node）授权、基于属性的访问控制（Attribute-based access control ABAC ）、基于角色的访问控制（ Role-based access control RBAC）、基于钩子（Webhook）方式的授权，目前业界使用RBAC机制较多。
准入控制器（Admission Controller）
Kubernetes包含许多准入控制器，其中有两个特殊的准入控制器：
- MutatingAdmissionWebhook
变更准入控制器，可以拦截并修改Kubernetes API Server请求的对象。 - ValidatingAdmissionWebhook
验证准入控制器，可以对Kubernetes API Server请求对象的格式进行校验，但无法修改对象。
集群管理员可通过修改kube-apiserver配置文件启动以上两个准入控制器:
–enable-admission-plugins=NodeRestriction， MutatingAdmissionWebhook,ValidatingAdmissionWebhook
准入控制过程主要分为两个阶段，第一阶段运行变更准入控制器，第二阶段运行验证准入控制器，需要注意的是，Kubernetes的某些准入控制器既是变更准入控制器也是验证准入控制器。如果第一阶段的任何准入控制器拒绝了请求，则整个请求被拒绝，并同时会向终端用户返回一个错误。
Secret
Kubernetes使用Secret对象来保存敏感信息，例如密码、令牌和SSH密钥。相比于将敏感信息放入Pod定义的yaml文件或容器镜像中，使用Secret方式更为安全灵活，该方式也是目前开发者常使用的密钥管理方式。在传递至容器的过程中，主要有将Secret构建至容器镜像中，通过Kubernetes环境变量，挂载宿主机文件系统三种方式。
网络策略（Network Policy）
随着应用在云原生环境中的逐步落地，应用上云后带来了诸多网络层面的问题，例如应用间的网络调用需求大规模增长，应用间的流量控制变得尤其复杂，面对这些问题，Kubernetes在1.3版本引入了网络策略，其主要用于在网络三四层提供流量控制能力，网络策略以应用为中心，允许用户设置Pod与网络中各类实体间的通信。
网络策略需要通过网络插件来实现，由于某些网络插件不支持网络策略，例如Flannel，因此策略即使下发成功也不会生效。支持网络策略的网络插件包括但不限于Calico、Cillum、Weave等。
默认情况下，Pod间是非隔离的，接受任何来源的流量。当为某一命名空间下的Pod下发网络策略时，该Pod会拒绝该网络策略所不允许的连接，其他命名空间的Pod继续接收流量。此外，网络策略通常不会冲突，是累加的并且最终取并集，不会影响策略结果。
五、Kubernetes未来演进趋势
图9 Kubernetes未来演进趋势示意
在本次RSA演讲中，Max vonBlankenburg和Lenin Alevski谈到Kubernetes的演进趋势，认为Kubernetes将会以更多的形态（K3s、Minikube、Kubeedge）部署在边缘云和混合云场景中，笔者也对此表示认同，未来的云原生技术将赋能于各类新型基础设施，如5G、边缘计算、工业互联网等，云原生安全将根据不同场景的特点、需求和约束条件，演化出多种技术发展路线，最终形成相应的新基建安全防护方案。此外，随着企业上云、SDWAN兴起，安全访问服务边缘（Secure Access Service Edge，SASE）技术将会把各类安全技术与网络、云基础设施融合，提供融合私有云、公有云、多云、混合云和传统IT环境等复杂场景下统一的端到端安全连接，这种环境变化，将催生新形态的安全能力和安全交付模式。
六、总结
从今年的RSA议题和创新沙盒入围的安全初创公司可以看出，云安全仍然是不可或缺的热门话题之一。云原生概念自被提出以来，企业业务云原生化改造在国内外各行业都已得到大规模实施。安全伴随业务，随之而来的便是云原生安全，特别是容器安全和 Kubernetes 安全。Gartner近年也提出了CNAPP的概念，这预示着云原生防护体系将会不断完善。本次议题中Max vonBlankenburg和Lenin Alevski 全面阐述了Kubernetes 的常见攻击手法，并提出了相应的安全建议，为企业在云原生安全实际落地过程中提供了有价值的参考。
参考文献
[2] https://owasp.org/www-project-kubernetes-top-ten/
[3] RSAC 2024 Kubernetes Security Attacking and Defending Modern Infrastructure.pdf