文章总结： 本文揭示了KubernetesOperator中的跨命名空间引用漏洞，攻击者利用声明与执行范围不匹配诱导高权限Operator操作其他命名空间资源，击穿隔离防线。测量显示14%的Operator受影响，已获多个CVE。研究提出了基于准入控制的无损防御方案，有效拦截恶意请求且性能开销极低。 综合评分： 90 文章分类： 云安全,漏洞分析,解决方案,代码审计,漏洞POC

G.O.S.S.I.P 阅读推荐 2025-12-31 Breaking the Bulkhead

Ziyi

安全研究GoSSIP

2025年12月31日 21:44 德国

Kubernetes Operator 作为云原生自动化的核心组件，因其强大的功能和极高的权限，正日益成为攻击者眼中的高价值目标。然而，现有的安全研究主要集中在配置错误或容器逃逸上，针对 Operator 逻辑缺陷的系统性安全研究仍是一片空白。本文揭示了一类新型漏洞——跨命名空间引用漏洞（Cross-Namespace Reference Vulnerability） 。该漏洞源于 Operator 资源声明范围（Declared Scope）与实际执行逻辑范围（Implemented Scope）的不匹配：攻击者只需在拥有权限的命名空间内创建恶意配置，即可诱导高权限的 Operator 非法操作其他受保护命名空间的资源，甚至直接篡改集群级配置，击穿 Kubernetes 的 Namespace 隔离防线 。

研究团队开发了一套静态分析工具，对 GitHub 上 2,268 个真实的 Operator 进行了大规模测量 ：超过 14% 的 Operator 受到此类漏洞影响 ，波及范围涵盖 Red Hat、NVIDIA 等知名厂商 。截至目前，团队已收到 8 个漏洞确认，并获批 7 个 CVE 编号（如 CVE-2025-29781, CVE-2025-2842 等）。针对这一威胁，团队还提出了一种无需修改 Operator 源码的准入控制防御方案，为云原生生态提供了切实可行的防护建议 。

Background

在深入漏洞之前，需要理解 Operator 是如何工作的。Operator 的核心是 Custom Resource (CR)。用户像填写表格一样创建一个 CR，Operator 就会根据这个表格去干活。

如上图所示，这是一个声明数据库实例的 CR。通常情况下，CR 是 Namespace-scoped（命名空间级） 的资源。这意味着，如果你只拥有 Team-A 命名空间的权限，你就只能在 Team-A 里创建这个 CR。这本该是 K8s 隔离机制的第一道防线。然而，Operator 本身通常拥有跨 Namespace 的高权限，这就为后续的权限穿透埋下了伏笔。

Threat Model

我们的威胁模型假设攻击者是一个普通的 K8s 用户（例如多租户环境中的一个租户），他被限制在自己的 Namespace（攻击者命名空间）里，无法访问别人的 Namespace。

这张图展示了攻击的核心逻辑（Cross-Namespace Reference Attack）：

1. 左侧（Attacker Namespace）： 攻击者在自己合法的地盘里，创建了一个 Malicious Resource（恶意资源）。
2. 中间（Vulnerable Operator）： 这个拥有高权限的 Operator 并没有意识到危险，它读取了这个资源。
3. 右侧（攻击路径）：

   – 路径 I (上路)： Operator 听从指挥，去操作了 Victim Namespace（受害者命名空间）里的 Secret 或 ConfigMap。

  – 路径 II (下路)： Operator 听从指挥，去操作了 Cluster-Scoped Resource（集群级资源），进而影响整个集群的所有命名空间。

更加细节的讲解如下：

窃取Secret (Insecure NS-Scoped Reference)

• 上半部分（YAML）： 攻击者提交的 CR。

    -注意第 6 行：namespace: attacker —— 这是合法的，资源创建在攻击者自己的namespace。

    -关键点在第 11 行： namespace: victim —— 攻击者在 spec 字段里指定了受害者的命名空间。

• 下半部分（Go 代码）： Operator 的逻辑。

    -第 9 行：Namespace: secretRef.Namespace。Operator 直接读取了攻击者填写的 victim 字段。

    -第 13 行：r.Get(…)。Operator 利用自己的高权限，直接从 victim 命名空间里把 sensitive-secret 抓了出来。

篡改集群权限 (Insecure Cluster-Scoped Reference)

• 上半部分（YAML）： 攻击者提交的 CR，依然是在 attacker 命名空间。

• 下半部分（Go 代码）：

    -第 2 行：Operator 准备创建一个 ClusterRoleBinding（这是集群级资源，权限极高）。

    -第 7 行：Namespace: app.Namespace。Operator 将这个高权限绑定给了攻击者命名空间下的 ServiceAccount。

    -第 11 行：r.Create(…)。Operator 执行创建。

Measurement

为了验证这个问题的普遍性，作者设计了一个静态分析工具，用于大范围measurement。

Step I: 从 GitHub 抓取了 2,268 个 Operator。

Step II : 自动识别哪些是 Namespace-scoped 资源（左上），哪些是 Cluster-scoped 资源（左下）。

Step III: 使用 污点分析 (Taint Tracking)。我们追踪数据流（红线部分），看攻击者控制的数据（如 spec.namespace）是否最终流向了敏感的操作函数（如客户端的 Get 或 Create 方法）。

结果显示 14% (318个) 的 Operator 存在此类漏洞。其中 8.6% 涉及跨命名空间窃取，7.7% 涉及集群资源篡改。

数据显示，最常见的操作是 Get (读取)，其次是 Create (创建)。这意味着信息泄露是当前最大的风险。

在 Realworld 层面，作者向Providers报告了对应的漏洞，目前已经有多个漏洞confirmed，分配了CVE number。

Mitigation

既然 Operator 的业务逻辑确实需要这些权限，那就不能简单地封杀它们。作者提出了一种“外挂式”防御方案。

基于准入控制的防御架构

这张图展示了防御流程：

1. 拦截 (Step 1-2): 当请求发往 K8s API 时，我们的 Webhook 会先拦截它。
2. 校验 (Step 3): Webhook 发起一个 SubjectAccessReview 查询：“这个发起请求的用户（User），真的有权限访问他配置里写的那个目标资源吗？”
3. 决策 (Step 4-5): 如果 K8s 说“无权访问”，Webhook 直接拒绝请求，Operator 根本不会收到这个恶意 CR。

Webhook 的简化代码实现

• 第 6 行：提取引用的目标命名空间 (secretNs)。
• 第 7-16 行：构造权限检查请求 (SubjectAccessReview)。
• 第 19 行：如果 Allowed 为 false，直接报错拒绝。

这种方法不需要修改 Operator 的任何源码，即插即用。

同样的，作者在之前发现的realworld的漏洞基础上进行了性能的测试：

其结果表现为性能开销极低（仅增加约 4ms 延迟）。

论文下载：https://arxiv.org/pdf/2507.03387

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全研究GoSSIP Ziyi《G.O.S.S.I.P 阅读推荐 2025-12-31 Breaking the Bulkhead》