How To Break Multi-Tenancy Again and Again in Kubernetes ...and What We Can Learn From It

Implementing Kubernetes namespace-based multi-tenancy is challenging, and its isolation is generally considered less effective than control-plane isolation. That’s why the latter is often recommended … and also implemented? Not really, as workloads such as machine learning, pipelines, and scripting capabilities are increasingly common in enterprise environments. And they can introduce unobvious multi-tenancy in clusters.

So the question is: How can we securely isolate those workloads from each other? Pod Security Standards, Network Policies, and Admission Controls are well adopted, but are they sufficient?

The answer is no – this talk presents new vulnerabilities and real-world exploits in Kubeflow, Istio, and Traefik that violate trust boundaries between namespaces and workloads.

We will discuss these vulnerabilities in detail, together with the underlying conditions and root causes that render them exploitable.

Based on these examples, we will present a methodology for assessing complex environments with isolation problems and provide guidance on mitigating these issues.

Please do not show the following information publicly:

Presentation Outline

(1) Flavors of multi-tenancy & architectural approaches

• Common security expectations for namespace-based multi-tenancy
• Our research question: Is industry-best practice hardening enough to isolate namespace-based multi-tenancy?
• Quick overview of our research approach, which technical steps/analyses we performed etc.

(2) Classes of vulnerabilities that commonly break namespace-based multi-tenancy

• Insecure Cross-Namespace References in Custom Resource Definitions (CRDs)
• Insecure Cross-Namespace References in Annotations
• Insecure Cross-Namespace References on the data plane

Examples:

(2.1) Kubeflow

A Kubeflow setup based on the official manifests and most other packaged Kubeflow distributions is vulnerable to the theft of authorization tokens by any user of the Kubeflow UI or APIs, such as the Dashboard, Pipelines API, or Notebooks. With this token, the attacker can take over the user’s account and the data that is processed by that user.

The default-editor service account accessible by any workload allows a user to create Istio VirtualServices on any Istio Gateway in the cluster.

Thus, an attacker can create a VirtualService on the Kubeflow gateway and overwrite existing paths on the Kubeflow site, including components such as the Dashboard, Pipelines API, or Notebooks.

(2.2) Istio: Insecure Cross-Namespace References in Istio’s CRDs leading to man-in-the-middle scenarios in namespace-based multi-tenant setups

Istio’s traffic routing configuration operates at the mesh level, meaning that routing rules defined in one namespace will influence traffic originating from workloads in other namespaces. An attacker who has permission to create or modify VirtualService resources can abuse this behavior by defining routing rules for arbitrary hosts. This allows an attacker to create a malicious VirtualService that matches requests for specific hostnames and redirects them to an attacker-controlled service. As a result, traffic from other workloads in the mesh can be transparently routed through the attacker’s service before reaching its intended destination. Istio’s mutual TLS authentication does not help here, because the proxy identifies the attacker-controlled service as the legitimate destination of the overwritten hostname.

(2.3) Traefik

Traefik in Kubernetes (K8s) allows cross-namespace access to Traefik resources when using Annotations on Ingress and Service resources.

An attacker can include these resources in an Ingress or Service configuration and thereby partially bypass namespace-based tenant isolation. In certain cases, this will give an attacker access to data of services in other namespaces, for instance:

• If a middleware adds an API access token through the Header middleware, an attacker can steal this token.
• An attacker could include a ServersTransport that does client certificate authentication against a service to access this service.
• An attacker could include a ForwardAuth middleware to gain access to the internal response headers of the forward auth service and thus steal internal tokens.

(3) Discussion of our methodology to evaluate & mitigate an individual environment

The methodology assumes that industry best practices, such as NetworkPolicies, Role-Based Access Control (RBAC), and Pod Security Standards, are already in place. These measures provide a necessary baseline level of protection against well-known isolation threats. However, they are insufficient to address a class of more subtle attack vectors arising from interactions between tenants and shared components. Such attack vectors may still compromise the confidentiality, integrity, and availability (CIA) of the cluster and its workloads, even in well-hardened environments.

The approach consists of three sequential phases:

1. Determining whether Namespace-based Multi-Tenancy is present in the assessed environment
2. Assessing potential weaknesses by analyzing tenant capabilities and their interactions with shared components
3. Addressing identified weaknesses through appropriate remediation strategies.

This methodology is not limited to Namespace-based Multi-Tenancy. It can also be applied to environments that use hard coupling between tenants, such as clusters connected through a shared service mesh. In these scenarios, tenants continue to interact with common control plane components, which may introduce similar risks.

(4) Conclusions and future work

Problem Statement

In many multi-tenant Kube cluster deployments, namespaces are considered trust boundaries. In reality, they’re often not as subtle; configuration elements of core components can lead to various cross-tenant attack scenarios.

Audience Takeaways

We hope to provide the following to the audience:

• Thorough understanding of the security implications & pitfalls of namespace-based multi-tenancy
• How attackers can exploit typical configurations of some very popular projects/components
• How to properly harden these elements
• How to apply a consistent methodology to identify these types of issues in complex cluster deployments

Disclosure status

All vulnerabilities have been disclosed to the respective projects. CVEs for the vulnerabilities are work-in-progress as of the time of the submission, but all projects are aware of the planned talk, and GitHub security advisories have been assigned (not public as of the time of submission)

• Traefik: GHSA-rh7m-2m44-x32f. In addition, they have already updated their Multi-Tenancy security documentation accordingly.
• Kubeflow: GHSA-v824-8gxh-pgjw & GHSA-qjw6-hpc7-w36h
• Istio issued security bulletin ISTIO-SECURITY-2026-002 (to be published together with an updated security model)