深入 K8s API 安全：发现隐藏在 API 中的秘密

近日，京东安全獬豸实验室携最新技术研究，在 Black Hat Asia 2025上，与参会者进行了广泛而深入的交流 。京东安全实验室研究员分享了 "KubeAPI-Inspector: discover the secrets hidden in apis" 的议题，与参会者探讨了 Kubernetes Extension API Server 在特定场景下存在的安全漏洞，以及如何开发一款工具来发现潜在的 K8S API 安全风险。该工具也为弥补目前鲜有面向 K8s API 安全检测的开源工具这一短板提供了一些思路和方法。

Kubernetes 具备优秀的可扩展性，就像一块乐高底板，而 Extension API Server、Controller 以及准入 webhook 则是可以添加各种功能的乐高积木。企业可以通过这些机制扩展 K8s 的核心功能，满足定制化需求，如构建复杂的 PaaS 平台、多租户隔离能力、多云集群架构亦或是当前火爆的 AI/ML 工作流。

然而，这种扩展机制也引入了新的安全风险。知名云安全公司 Wiz 近期披露的 "IngressNightmare" 漏洞恰恰证明了这一点。使用该漏洞攻击者可以在特定配置下通过精心构造的 AdmissionReview 对象，在集群中执行任意代码从而接管整个集群。那么，同样作为 K8s 扩展机制之一的 Extension API Server，在某些场景下是否也隐藏着尚未被发现的风险呢？

K8s 以声明式 API 为核心，可以说“一切皆 API”。无论是用户、控制平面组件（如 Kubelet、Controller Manager），还是外部系统，都必须通过 API Server 进行通信和交互。

一般情况下，创建 CustomResourceDefinition (CRD) 对象即可在 K8s API Server 中完成新的数据类型注册，并且根据资源定义自动生成 OpenAPI Schema，一同合并到 API Server 的 OpenAPI 端点。创建 CRD 后，开发者可以像使用内置资源一样，对自定义资源 (Custom Resource, CR) 进行 CRUD 操作，并根据 API 定义实现 Operator/Controller 的处理逻辑，从而完成集群的功能扩展。

如果业务需求相对复杂，例如需要自定义 subresources 或实现复杂的 authz/authn 功能，K8s 还提供了另一种扩展功能机制 —— Extension API Server。这种机制允许开发者按照 Kubernetes API 规范添加自定义 API，并以“独立”API Server 的形式处理特定 API 组（例如 workshop.io/v1）的请求。为了使主 K8s API Server 感知到新的 API，需要通过 APIService 对象进行注册，将特定 API 组的请求转发至指定 Service 对应的 Extension API Server（见扩展 API 工作流程图）。此外，Extension API Server 需要自行提供 OpenAPI 端点，供主 APIServer 聚合和公开 API 定义。

当使用 Extension API Server 机制增强功能时，K8s APIServer 充当聚合/代理转发的角色。请求通过主 K8s API Server 认证后，将会转发至Extension APIServer。路由系统会根据请求的 GVR (Group Version Resource) 和 HTTP 方法匹配到对应的 REST Handler。通常情况下，开发者会参考 K8s 官方示例项目，使用“结构体嵌入”（方法提升）特性来实现默认的 CRUD 逻辑。另外，开发者也可以根据需求，按照 rest.StandardStorage 的定义自行实现 CRUD 处理逻辑。

这里列出了 K8s REST 所支持的一些方法及其对应的 REST Handler 方法。标红部分是开发者常会忽略并采用默认实现的点。此外，我们可以构造参数或访问端点，使用不同的 API Verb 来访问不同的 REST Handler。

在整个研究过程中，我们发现部分开源项目在使用此特性时，可能会产生绕过自定义过滤器的风险，严重时可能导致整个集群连接凭证的泄露，从而实现对集群的接管。接下来，让我们先了解此特性的工作原理，并揭开漏洞的真面目。

我们以某个开源项目中存在的漏洞为例。该项目是一个含有复杂功能的多集群/多租户集群管理系统。为了满足业务需求，开发者实现了比 K8s RBAC 更细粒度的访问控制，并在 REST Handler 中使用了自定义过滤器来过滤部分结果输出。然而，在应用自定义过滤器时，开发者只覆盖了常用的方法，并没有覆盖全部的处理方法，而另一些方法则依赖于嵌入结构体中“提升”上来的默认实现。

那么问题来了，在 K8s 官方提供的 rest.StandardStorage 默认实现上，并没有开发者所期望的自定义过滤器应用，而开发者又没有在主结构体中显式地覆盖并添加检查，那么攻击者就可以通过模拟请求调用这些未被充分保护的方法（如 DeleteCollection，Watch），绕过预期的自定义访问控制！

我们通过一个直观的例子描述此漏洞的发生过程。Cluster 对象是一个 cluster-scope (non-namespaced) 的 API，并且在 RBAC 授权角色绑定时会给予租户正常的读写权限。开发者通过 Cluster spec 中的 tenant 字段与请求上下文传递的身份信息进行匹配，以实现权限校验。在正常情况下（如下图所示），当租户 1 使用 Get Verb 访问自己拥有的 Cluster 资源时，Extension APIServer 会应用自定义的过滤器，仅从 ETCD 获取并返回当前上下文所传递用户拥有的集群对象。

在非预期的情况下，攻击者可以在请求的 URL 中增加适当的参数，例如 ?watch=true&timeoutSeconds=2，使发起的 API 请求路由匹配到“提升”的 Watch 默认方法实现，从而绕过自定义过滤器，导致 ETCD 泄露所有存储的 Cluster 对象。

基于上文提到的 API 工作原理，我们了解到，无论是通过 CRD 注册还是 Extension APIServer 的形式，都需要声明资源的所有字段定义（甚至可能包含一些注解常量定义），以便 K8s 能生成获取对应资源的 OpenAPI 文档。另外，K8s 默认为 Pod 挂载的服务账号 (ServiceAccount) 授予了 OpenAPI 端点的访问权限。因此，我们可以围绕这两个核心点，解析 OpenAPI 定义，并实现相应的检测过程。

在自定义 API 发现方面，我们采用了 client-go 所包含的 DiscoveryClient ，以实现发现 K8s 所有 API 端点，其原理是访问 /apis 接口获取所有已注册的 API 组，并循环访问每个 API 组的版本以获取资源列表。通过这种方法，再结合 OpenAPI 端点定义的 API 结构，即可找到所有待测目标。

为了覆盖所有的 API Verb 请求，其中包括可能中断流程或执行危险操作的方法，如 Watch、DeleteCollection，在 Kubernetes 的 rest.Storage 实现中可以发现，Kubernetes 开发者为 API Verb 开发了许多可选参数，其中包括 dryRun 模式以及限制请求长度和时间的选项。这样，我们就可以使用 dryRun 安全地覆盖检测 DeleteCollection 方法。

同时，我们还精心制作了一个真实存在的漏洞靶场，可以通过 YAML 文件快速搭建，旨在帮助更多安全从业者和 Kubernetes 研发人员理解漏洞成因。

如需了解更多详情，请访问该项目开源地址：https://github.com/yeahx/KubeAPI-Inspector。

Kubernetes 可扩展性虽然强大，但也带来了新的安全风险，知名云安全公司 Wiz 发现的 “IngressNightmare” 严重漏洞为此敲响了警钟。希望通过分享此次研究发现，能够使大家了解到不当使用 Extension API Server 机制同样存在安全风险，并为发现和检测此类漏洞提供一些思路。

獬豸实验室正在招募各路英雄，欢迎加入崇尚技术创新、用技术守护互联网安全的我们。