文章总结： ERNW研究者在BlackHatUSA2026展示了Kubernetes多租户隔离的系统性突破，包括CRD跨namespace引用、Kubeflow权限提升、Traefikannotation劫持及Notebook钓鱼。核心结论是namespace边界假设不足，租户可控对象与触达资源间的边界模糊。建议采用识别、评估、修复方法论，并强调AdmissionControl在资源持久化前拦截跨namespace引用的关键价值。 综合评分： 88 文章分类： 漏洞分析,渗透测试,红队,云安全,安全建设

Kubernetes 多租户隔离的反复突破

原创

AIxSec69 AIxSec69

AIxSec69

2026年8月16日 20:34 美国

在小说阅读器读本章

去阅读

Kubernetes 多租户隔离的反复突破：从 CRD 引用到数据面劫持

来源：Black Hat USA 2026 Briefings

标题：Breaking Multi-Tenancy Over and Over, and What We Can Learn From This

作者：Lorin Lehawany & Sven Nobis（ERNW）

适合读者：Kubernetes 安全工程师、平台安全团队、云原生安全研究者、SRE 工程师

简介：你以为 RBAC + NetworkPolicy + Pod Security 就够了？ERNW 研究者展示了 namespace 多租户隔离在 CRD 跨 namespace 引用、Ingress/Gateway 配置、Notebook 镜像、数据面流量劫持等方面的系统性突破——从 Kubeflow 到 Traefik 到 Istio，一个比一个隐蔽，还附带一套识别→评估→修复的方法论。

◆ ◆ ◆

Kubernetes 的多租户隔离基于一个简单的假设：namespace 是边界。RBAC 控制谁能做什么，NetworkPolicy 控制流量，Pod Security 控制运行时。行业最佳实践告诉你：把这些配好，多租户就安全了。

ERNW 的两位研究者给了一个简短的答案：不，不够。

他们在 Black Hat USA 2026 上展示了对 Kubernetes 多租户平台的系统性审计，发现了一类被普遍忽视的问题——命名空间资源可以通过控制面（control plane）和数据面（data plane）对集群内的其他 namespace 甚至集群外产生影响。更关键的是，他们发现的不是孤立的 CVE，而是一整套可复用的攻击模式。

什么是”跨 Namespace 引用”

先理解核心概念。Kubernetes 的 Custom Resource Definition（CRD）操作符经常在一个 namespace 中创建 CR 实例，而在另一个 namespace 中产生副作用。研究者把这个模式称为 Cross-Namespace References（跨命名空间引用）——一个 CR 的 spec 里引用另一个 namespace 的资源，而操作符不加验证地将引用解析到其他 namespace。

▲ 跨 Namespace 引用的概念：一个 CR 的 spec 引用另一个 namespace 的资源（来源：Black Hat USA 2026 Slides）

这类引用的危险在于：租户能控制 CR 的 spec，而操作符替攻击者完成跨边界的操作。 攻击者不需要高权限，只需要能提交一个精心构造的 CR。

Kubeflow 案例：从默认编辑器到 Cluster Admin

第一个真实案例是 ML 工作负载平台 Kubeflow。研究者发现，Kubeflow 的默认 Service Account default-editor 拥有过宽的权限——能创建 configmap、secret，甚至能编辑 Istio VirtualService。

攻击路径分三步：

第一步，容器命令注入。 Kubeflow 的 InferenceService CR 允许用户在 spec.predictor.containers 中注入任意命令。攻击者构造一个包含 kubectl create secret 的容器启动命令，Kubeflow 的操作符会忠实地在攻击者指定的 namespace 中执行这些命令。这是最典型的跨 namespace 引用利用——攻击者在自己的 namespace 里提交 CR，副作用发生在受害者的 namespace。

第二步，Istio VirtualService 劫持。 由于 default-editor 有 Istio 编辑权限，攻击者可以创建恶意 VirtualService。Istio 的 VirtualService gateways 字段如果设置为 mesh，会将路由规则应用到网格内所有 sidecar；如果指向 kubeflow/kf-gateway，就能劫持进入 Kubeflow 的全部流量。

▲ Istio VirtualService 劫持：gateways 指向共享网关，重定向租户流量（来源：Black Hat USA 2026 Slides）

第三步，绕过 NetworkPolicy。 研究者进一步展示，即使集群配置了 NetworkPolicy，VirtualService 劫持依然有效——因为 NetworkPolicy 限制的是 Pod 之间的网络连接，而流量劫持发生在 Istio 控制面层面。攻击者把发往受害者的请求重定向到自己的 Pod，NetworkPolicy 完全看不见。

▲ 绕过 NetworkPolicy：流量劫持发生在 Istio 控制面，NetworkPolicy 无法拦截（来源：Black Hat USA 2026 Slides）

结果：攻击者拿到受害者的会话 cookie（oauth2\_proxy\_kubeflow），甚至能通过 poc-cluster-admin-token 实现纵向提权到 Cluster Admin。这个案例已被 CVE-2026-47237 记录，Kubeflow 通过移除 Service Account 的 Istio 编辑权限修复。

Traefik 案例：Annotation 里的隐蔽引用

第二个案例更隐蔽——问题藏在 Annotation（注解） 里，而不是 CR 的 spec 里。

Traefik 通过 Service 的 annotation（如 traefik.ingress.kubernetes.io/router.tls.certresolver）配置路由和 TLS。研究者发现，Traefik 的 ServersTransport CR 中的 certificatesSecrets 字段可以引用其他 namespace 的 TLS 证书密钥。

▲ Traefik 案例：ServersTransport 通过 annotation 跨 namespace 引用 TLS 密钥（来源：Black Hat USA 2026 Slides）

攻击者在自己的 namespace 创建一个 Service，通过 annotation 引用受害者 namespace 的 TLS 密钥。Traefik 代理会忠实地为攻击者的服务加载受害者的证书——攻击者拿到了受害者域名对应的有效 TLS 证书。这个案例正在被 Traefik 修复，官方建议迁移到 Gateway API。

Notebook 钓鱼：共享资源模型的架构性弱点

研究者还展示了一个不依赖任何”漏洞”的攻击——Notebook 钓鱼。

攻击者在共享 namespace 里创建一个自定义镜像的 Notebook（镜像里包含凭证窃取逻辑），然后授权受害用户访问。诱使受害者点击链接访问该 Notebook——一旦受害者与 Notebook 交互，恶意镜像就拿到了受害者的凭证。

▲ Notebook 钓鱼：自定义镜像 + 授权受害者访问 = 凭证窃取（来源：Black Hat USA 2026 Slides）

这不是传统的代码漏洞——这是云原生平台中共享资源模型的架构性弱点。当一个租户能在共享空间里创建”看起来正常”的资源并诱骗其他人交互时，隔离假设本身就不成立了。

方法论：识别 → 评估 → 修复

研究者把这次研究提炼为一套可复用的方法论，任何 K8s 多租户平台都能套用：

1. 识别（Use/Identify）：哪些资源在租户的控制之下？哪些控制面交互和数据面流量跨越了 namespace 边界？特别要检查：CR 的 spec 里有没有引用其他 namespace 的字段？Annotation 里有没有跨 namespace 的引用？回答这两个问题就找到了潜在弱点。

2. 评估（Assess）：对已识别的交叉引用评估影响——信息泄露？权限提升？DoS？数据面劫持？研究者特别指出要问：“如果这个租户是恶意的，他能不能影响到其他 namespace？” 而不是假设所有租户都按文档使用平台。

3. 修复（Address）：优先级从低到高——部署厂商补丁 → 使用已有的 admission policy 集合（如 Kyverno/Gatekeeper）→ 定义自定义策略。研究者特别强调了 Admission Control 的价值：在资源被持久化到 etcd 之前拦截，这是 Kubernetes 安全模型中最有效但最被低估的防御层。

▲ Admission Control 策略：在资源持久化到 etcd 之前拦截跨 namespace 引用（来源：Black Hat USA 2026 Slides）

关键的策略模式包括：限制 CR 中的 namespace 字段为当前 namespace、阻止 VirtualService 使用 mesh gateway、限制 Notebook 镜像来源、以及用 Kyverno/Gatekeeper 校验 annotation 中的跨 namespace 引用。

一个统一的教训

把三个案例放在一起看，会看到一个共同模式：“租户能控制的对象”与”该对象能触达的资源”之间的边界，远没有平台文档宣称的那么清晰。 CRD 操作符解析引用、Ingress 控制器读取 annotation、Notebook 服务加载镜像——每一次”便利的自动解析”都可能成为跨租户的通道。

ERNW 研究者的结论很务实：如果你的 K8s 集群上跑了多个团队的工作负载——不管是有意还是无意——这套”识别→评估→修复”的方法论值得在你的环境中执行一遍。多租户安全不是配置几个最佳实践就完事，而是要持续地追问：还有哪些边界是我没看到的？

◆ ◆ ◆

原文链接：https://www.blackhat.com/us-26/briefings/schedule/#breaking-multi-tenancy-over-and-over-and-what-we-can-learn-from-this-54060

免责声明：

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

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

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

本文转载自：AIxSec69 AIxSec69 AIxSec69《Kubernetes 多租户隔离的反复突破》