2021 年 2 月，Google 发布了 Autopilot，这是 Google Kubernetes Engine (GKE) 中的一种新操作模式。借助 Autopilot，Google 提供了“无需干预”的 Kubernetes 体验，为客户管理集群基础设施。该平台会根据资源消耗自动配置和删除节点。

2021 年 6 月，Unit 42 研究人员向 Google 披露了 GKE Autopilot 中的多个漏洞和攻击技术。能够创建 pod 的用户可能会滥用这些来进行以下操作：

1. 逃离他们的 pod 并破坏底层节点；

2. 提升权限并成为完整的集群管理员；

3. 通过对集群操作人员完全不可见的后门秘密地保持管理访问。

例如，一个攻击者通过一个被攻击的开发人员帐户在Autopilot集群上获得了初始的立脚点，可能已经利用这些漏洞来提升权限并成为“影子管理员”，能够秘密泄露机密、部署恶意软件或加密挖矿软件以及中断工作量。

披露之后，Google 修复了报告的漏洞，在 GKE 中部署了补丁。所有 Autopilot 集群现在都受到保护。

GKE Autopilot 的背景

Autopilot 是 GKE 中的一种新操作模式，提供了 Google 所描述的“无需干预”的 Kubernetes 体验。在 GKE Standard中，客户管理他们的集群基础设施并按节点付费。借助 GKE Autopilot，Google 负责集群基础架构，客户只需为其运行的 pod 付费。这使客户可以专注于他们的应用程序，从而降低运营成本。

简而言之，托管集群基础架构意味着会实现Google自动自动化 ：

根据你的 pod 的资源消耗来配置和调整节点的数量；

强制执行内置策略，以确保集群遵循安全的最佳做法并且可以由 Google 安全管理。

下面是 Autopilot 架构的简化图。 Autopilot 独有的组件以绿色显示，并以与上面列表中的角色相对应的数字显示。与 GKE Standard 不同，其中节点作为 Compute Engine 虚拟机可见，Autopilot节点完全由谷歌管理，因此用绿色表示。

GKE Autopilot 架构

如上图所示，两个组件强制执行 Autopilot 的策略。首先是一个OPA Gatekeeper认证的webhook，这是一个广泛用于 Kubernetes 中的策略执行的开源项目。第二个是Kubernetes的私有授权模式GKEAutopilot，它是谷歌通过修改Kubernetes源代码实现的。

内置策略有两个目的：1.防止用户访问由 Google 管理的集群组件，如节点；2.维护安全的 Kubernetes 最佳实践。例如，Autopilot 禁止运行特权容器，同时满足1.和2.。

Autopilot 的内置策略阻止特权容器（Gatekeeper）

Autopilot 的政策不仅仅是防止逃逸，图 3、4 和 5 突出显示了一些有趣的示例。 GKE 的文档列出了该策略强制执行的每个限制。

kube-system 命名空间被管理，客户被限制为只读访问

用户不能列出或创建可变的准入 webhook

拒绝外部 IP 服务以防范 CVE-2020-8554

阅读上图中的错误信息，可以看到 Gatekeeper 阻止了图 2 和图 5 中的操作，而 GKEAutopilot 授权模式阻止了图 3 和图 4 中的操作。

GKE Autopilot 独有的攻击面

Autopilot 的内置策略可立即阻止多个利用路径，与标准 Kubernetes 或 GKE 标准相比，提供了更好的安全态势。话虽如此，它还创建了 Autopilot 独有的攻击面：

管理员可以依靠 Autopilot 的策略来防止有风险的配置。如果攻击者能够以某种方式规避该策略，他们可能会通过客户期望被阻止的方法提升权限，例如部署特权容器。

Autopilot 管理员没有完全特权，受到内置策略的限制，无法访问节点和某些特权 Kubernetes API。如果攻击者能够绕过 Autopilot 的策略，他们可能会获得比管理员更高的权限，从而为隐形后门打开大门。

以下部分介绍了我们发现的属于这些攻击面的漏洞、权限提升技术和持久性方法。链接在一起，它们允许可以创建 pod 的受限用户进行如下操作：

1. 破坏节点；

2. 将权限提升给不受限制的集群管理员；

3. 为集群安装不可见且持久的后门。

伪装成allowlistdworkload以破坏节点

Autopilot 在集群上安装了 OPA Gatekeeper 以及一些策略（在 Gatekeeper 术语中称为“限制”），负责防止特权容器等风险配置。该集群还有一个看起来很有趣的自定义资源定义 (CRD)，名为 allowlistedworkload。

Autopilot安装一个名为allowlistdworkloads的自定义资源定义(CRD)

如图 2 所示，Autopilot 禁止可能允许容器逃逸的 pod 配置。为了支持需要某种级别的节点访问的附加组件，Autopilot 创建了一个允许列出工作负载的概念。如果容器与列入白名单的工作负载匹配，则允许使用allowlistdworkload配置中指定的特权功能。 6 月，唯一被列入白名单的工作负载是 Datadog 代理。

Datadog代理allowlistedworkload

下面是引起我们注意的一个Datadog代理的允许列出的工作负载配置。如果容器指定了列出的命令和映像，则允许它在只读卷中挂载列出的主机路径。

Datadog代理的allowlistworkloadconfiguration示例之一

这里的问题是验证不充分，仅检查命令和图像不足以确保容器运行 Datadog 代码。使用下面的PodSpec，容器可以在运行受攻击者控制的代码时伪装成Datadog代理，并滥用已暴露的主机卷进行攻击。

伪装成 Datadog 代理

在下面的视频中，恶意用户部署了一个伪装成 Datadog 代理的 Pod。 Pod 通过以下步骤接管其底层节点：

滥用已挂载的 containerd 套接字来创建挂载主机文件系统的特权容器。

让该特权容器安装一个 systemd 服务，该服务从节点生成反向 shell 到攻击者控制的设备。

节点攻击的影响

可以创建 pod 的攻击者可能会利用此漏洞创建恶意容器，从而逃脱并接管其底层节点。 Autopilot 用户期望该平台能够阻止这种攻击。

节点攻击打开了以下攻击向量：

攻击者立即获得对相邻 pod 及其服务帐户令牌的控制权，从而可能提升权限并传播到其他命名空间。

攻击者可以查询节点的实例元数据端口以获取访问令牌。默认情况下，此令牌提供对客户项目中云存储的读取访问权限。

由于 Autopilot 管理员无法访问节点，攻击者可能会滥用此漏洞在其上安装隐蔽的恶意软件或加密挖矿软件。但是，Autopilot 会自动扩展节点，因此确保恶意软件持续存在并非易事。

攻击者可以访问底层的 Kubelet 凭证，从而可以看到几乎所有集群对象。

最后，因为 Autopilot 只对每个运行的 pod 计费，狡猾的用户可能会滥用这个漏洞来削减一些成本，直接在节点上运行一些工作负载。我们建议以更合理的方式减少开支。

升级为无限制管理员

研究人员可以寻找到可靠的方法将这个容器逃逸升级为一个完整的集群接管。通过破坏节点，攻击者可以窃取相邻 pod 的服务帐户令牌。自然，目标节点托管具有强大服务帐户的 Pod 是有意义的。这些可能是用户部署的 Pod，或者更有趣的是，在所有 Autopilot 集群中本地部署的系统 Pod。

在检查了内置策略后，我们发现 Autopilot 完全免除了 kube-system 服务帐户。这使得 kube-system pod 成为最有趣的目标，因为被盗代币可以自由使用而无需担心被发现。

为了在 Autopilot 中搜索功能强大的 pod，我们创建了 sa-hunter，这是一个 Python 工具，可以将 pod 的服务帐户映射到它们的 Kubernetes 权限（即角色和集群角色）。现有工具将服务帐户与其权限相关联，但不显示任何 pod 是否实际使用给定的服务帐户。下图显示了 sa-hunter 的示例输出：

sa-hunter 输出，将正在运行的 pod 与其权限相关联

sa-hunter 发现默认安装了两个强大的 kube-system pod：stackdriver-metadata-agent-cluster-level 和 metrics-server。两个 pod 都可以更新现有部署，如下图所示。这个权限乍一看可能看起来很无辜，但它足以升级为完整的集群管理员。有趣的是，这些 pod 也默认部署在 GKE Standard 中，使得以下权限提升技术与所有 GKE 集群、Standard 和 Autopilot 相关。

分配给 metrics-server pod 的特权角色可以更新部署

在接管托管 stackdriver-metadata-agent-cluster-level 或 metrics-server pod 的节点后，攻击者可以从节点文件系统中获取他们的服务帐户令牌。有了这个令牌，攻击者可以通过三个简单的步骤获得集群中任何服务帐户的权限：

将现有部署的服务帐户更新为目标服务帐户。有许多预安装的部署，其中任何一个都可用于此步骤；

将恶意容器添加到该部署；

让该恶意容器在 /run/secrets/kubernetes.io/serviceaccount/token 处检索挂载在容器中的目标服务帐户令牌。

滥用部署更新权限来获取任何服务帐户的令牌

要实现有意义的权限升级，攻击者需要针对功能强大的服务帐户。kube-system名称空间提供了许多预安装的、功能极其强大的服务帐户可供选择。clusterrole-aggregation-controller (CRAC)服务帐户可能是主要的候选者，因为它可以向现有的集群角色添加任意权限。

使用clusterrole- aggregate -controller服务帐户可以升级集群角色

在使用下图所示的技术获取 CRAC 的令牌后，攻击者可以更新绑定到 CRAC 的集群角色以拥有所有权限。此时，攻击者实际上是集群管理员，并且不受 Autopilot 策略的限制。

clusterrole-aggregation-controller 的令牌可以为其自身添加管理员权限

回顾一下，如果攻击者想要将这种特权升级技术与前面讨论的容器逃逸链接起来，他需要以某种方式将他的pod 安排在托管 stackdriver-metadata-agent-cluster-level 或 metrics-server pod 的节点上。尽管 Autopilot 拒绝具有 nodeSelector 的 pod，但它确实允许最简单的节点分配形式 - nodeName 字段。

nodeName 字段确保pod 将降落在目标节点上，只要它有足够的资源用于另一个 pod。即使目标节点上没有空间，攻击者仍然有几个选择。他可以进行以下操作：

1. 观察目标节点并等待一个 pod 被删除；

2. 创建 pod 以触发节点扩展，欺骗 Autopilot 的自动扩展器重新分配工作负载，以便强大的 pod 最终出现在更空的节点上。

通过 Mutating Admission Webhook 的隐形后门

下图展示了完整的攻击链，将容器逃逸与 GKE 中内置的提权路线相结合。在利用之后，攻击者拥有比 Autopilot 管理员更高的权限，因为他不受内置策略的限制。这种访问级别可以被滥用，以变异准入 webhook 的形式安装隐形和持久的后门。

允许webhook接收集群中创建或更新的任何对象，包括pod和secret。如果这还不够可怕的话，这些webhook还可以任意改变任何接收到的对象，使它们成为一个功能强大得可笑的后门。正如前所示，Autopilot管理员无法列出变异的admission webhook，因此永远不会看到这个后门。

通过不可见的变异准入 webhook 成为影子管理员

如果要管理功能强大的pod，请考虑是否可以从其服务帐户中删除不必要的特权，或者将它们限制在特定的名称空间或资源名称中。

攻击影响

在修复之前，攻击者可能已经利用出现的漏洞将有限的违规行为转变为对任何 Autopilot 集群的完整集群接管。使用对用户不可见的 webhook，攻击者可以秘密地保留他们的管理访问权限，从而有效地成为“影子管理员”。那时，他们可能已经秘密泄露了机密，部署了恶意软件或加密挖矿软件，并破坏了工作负载。

其他漏洞

另外，研究人员还发现了另外两个允许节点攻击但影响较小的漏洞。第一个涉及默认命名空间中不受 Autopilot 策略限制的两个服务帐户名称：csi-attacher 和 otelsvc。如果攻击者获得了对默认命名空间的控制权，则可以创建这些服务帐户来绕过内置策略。然后，攻击者可以创建特权 pod 来破坏节点，并使用讨论的特权升级技术来接管整个集群。

第二次攻击通过负载均衡器服务利用 CVE-2020-8554 来破坏节点，但需要管理员权限才能利用。这里的攻击场景是攻击者已经攻击了 Autopilot 集群，并希望绕过内置策略来建立隐蔽的后门。

防止对Kubernetes环境的类似攻击

本文提出的攻击可以归类为Kubernetes特权升级，其中具有有限访问权限的攻击者在集群中获得更广泛的权限。这种后续攻击者活动必须从最初的攻击开始：集群供应链中的恶意映像、易受攻击的公开暴露服务、被盗凭证或内部威胁。保护集群的软件供应链、身份和外部边界可以减少集群中发生此类攻击的机会。

老练的攻击者仍可能找到创造性的方法来渗透集群。主动解决常见的错误配置，比如kubelet允许未经身份验证的访问，可以显著减少攻击者可用的内部攻击面。网络策略和PodSecurityStandards等安全控制进一步限制和打击攻击者。

在该攻击链中，攻击者只需攻击一个节点就可以控制整个集群。潜在的问题不是节点的权限，而是它所托管的强大的节点的权限，包括更新部署的能力。乍一看，这个权限和其他权限可能会受到某种程度的限制，但它们等同于集群管理。

强大的pod在产品集群中仍然很常见：由底层Kubernetes平台本地安装或通过流行的开源插件引入。如果承载强大pod的节点受到攻击，攻击者可以轻松获取该pod的强大服务账户令牌并在集群中传播。

对付强大的pod是复杂的，主要是因为他们的许可可能是正当需要的。第一步是检测—确定集群中是否存在强大的pod。研究人员希望sa-hunter能在这方面有所帮助，他们计划发布更多的工具，专注于自动检测功能强大的pod。

如果你在你的集群中发现了强大的pod，我们建议采取以下方法之一:

1.如果要管理功能强大的pod，请考虑是否可以从其服务帐户中删除不必要的特权，或者将它们限制在特定的名称空间或资源名称中。

2.如果这些pod是外部解决方案的一部分，请联系相关的云提供商或项目，寻求减少pod的特权。如果pod由托管的Kubernetes服务部署，则可以使用控制平面控制器替换。

一些Kubernetes权限过于宽泛，这意味着有问题的pod可能不需要访问其权限暴露的危险操作。在这种情况下，可以实施一种策略(例如通过OPA Gatekeeper)来阻止pod执行某些危险的操作，或者更好的是，将pod限制为一组允许和预期的操作。

使用Taints、NodeAffinity或PodAntiAffinity规则将强大的pod与不可信或公开的pod隔离开来，确保它们不运行在同一个节点上。

总结

随着组织迁移到 Kubernetes，攻击者也纷纷效仿。最近的恶意软件样本（如 Silocape）表明，攻击者正在从简单的技术演变为高级 Kubernetes 定制攻击。针对老练的攻击者，仅仅保护集群的外围可能是不够的。

本文翻译自：https://unit42.paloaltonetworks.com/gke-autopilot-vulnerabilities/如若转载，请注明原文地址