Exactly one week ago, Sven and I had the incredible opportunity to give our very first talk at KubeCon + CloudNativeCon 2026: How To Break Multi-Tenancy Again and Again …and What We Can Learn From It. We discussed the challenges of namespace-based multi-tenancy and presented real-world exploits in Kubeflow, Istio, and Traefik that bypass threat boundaries between namespaces and workloads. Based on these problems, we developed a methodology to assess and address them. You can find the methodology discussed in the talk in detail in another blog post or on GitHub. You can also find the slides here.
This page introduces our structured methodology for assessing security risks in Kubernetes environments that use Namespace-based Multi-Tenancy. It addresses weaknesses that break Namespace-based isolation that not well studied, yet. We found this issues during our research and presented them together with this methodology in our Talk at KubeCon + CloudNativeCon Europe 2026.
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.
We reported a possible Man-in-the-Middle (MitM) attack scenario in which a VirtualService can redirect or intercept traffic within the service mesh. This affects Namespace-based Multi-Tenancy clusters where tenants have the permissions to deploy Istio resources (networking.istio.io/v1).
This blog post highlights the risks of using Istio in multi-tenant clusters and explains how users can mitigate these risks and safely operate Istio in their deployments.
The behavior described in this post applies to Istio version 1.29.0 and to all versions since the introduction of the mesh gateway option in the VirtualService resource.
Containerization dominates the market nowadays. Fancy buzzwords like continuous integration/deployment/delivery, microservices, containers, DevOps are floating around, but what do they mean? What benefits do they offer compared to the old dogmas? You’re gonna find out in our training!
We are going to start with the basics of Docker, Containers and DevOps, but soon you’ll end up with your own applications running inside containers with the images residing in your own registry. Of course, following the microservices approach, and the second day hasn’t even started.After the fundamental topics of containerization are understood, you’re going to create and operate your own Kubernetes cluster. A lot of fun and challenging exercises lie ahead, to give you hands-on experience with all the technologies.
We at ERNW have not only security written on our banner, it is a mindset we share. Therefore, be prepared to get knee deep into security in regards of the discussed technologies. We will tackle the security aspects from the bottom-up, what Containerization tools can offer and how all these can be enforced and enhanced with Kubernetes to secure your clusters. From there on you are ready for the final challenge. You will jump into the role of an attacker who did compromise a Container in the cluster and escalate your privileges to Cluster Admin.
Attendees who absolved the training will have a solid understanding of container technology, especially with Docker and Kubernetes and of course the security challenges those technologies bring to the table.
So, if you’re up to a challenging training and want to get not only your feet wet with Docker and Kubernetes, you can reserve your spot for the training right here.
This week I was at DevSecCon in London to present my current research on Red Hat OpenShift. In this talk, I gave a brief introduction to OpenShift, demonstrated some threats that exist for such environments, and dived into different configuration issues that may affect the security of OpenShift environments. The implications of misconfigurations of such an environment have been shown in live demos.