Multi-tenancy in Kubernetes is a paradox. Organizations want the cost-efficiency of a single cluster shared by multiple teams, but Kubernetes was never designed to be a “hard” multi-tenant system.
As a security researcher, I’ve found that “Tenant Admins”—users restricted to a single namespace—can often escalate to Cluster Admin using the very tools meant to keep them isolated. Here is how the “Namespace Escape” happens —and what you can do about it.
1. The “Namespace Label” Footgun
The most common mistake is allowing a user PATCH permissions on their own Namespace resource. While a namespace is a global resource, RBAC often treats it as “namespaced” to itself.
- The Attack: If your cluster uses Pod Security Admission (PSA), it likely enforces security based on namespace labels (e.g.,
baselinevsprivileged). - The Payload: An attacker simply re-labels their own namespace to
privileged. They can then deploy a “debug” pod that mounts the underlying host’s filesystem, effectively escaping the container and taking over the physical node.
2. The Confused Deputy: Abusing Operators
Kubernetes is “operators all the way down.” Many clusters use the Operator Lifecycle Manager (OLM) or specialized controllers to manage apps.
- The Risk: A tenant with
CREATEpermissions on wildcard resources can sometimes trick a high-privileged Controller into performing actions on their behalf. - The Result: By creating a specific “Subscription” or “OperatorGroup” resource, a tenant can force the cluster to install software with elevated Service Account permissions, bypassing their own RBAC restrictions.
3. Passive Recon via DNS
Even a pod with zero RBAC permissions can map your entire infrastructure. Because Kubernetes creates predictable DNS entries (svc.namespace.svc.cluster.local), any workload can brute-force the internal DNS server to discover every service and team name across the entire cluster.
How to Actually Secure Multi-Tenancy
If you are running a shared cluster, “Namespaces + RBAC” is not enough. You need Defense in Depth:
- Stop the Wildcards: Never grant
*permissions. Be explicit about which resources a user can touch. - Use Immutable Selectors: When writing Network Policies, use the immutable label
kubernetes.io/metadata.namerather than custom labels that a user might be able to change. - External Admission Controllers: Supplement RBAC with tools like Kyverno or OPA Gatekeeper to block “illegal” label changes or privileged pod specs.
- Hard Isolation: For high-risk workloads, the only true security boundary in Kubernetes is a separate cluster.
Summary Checklist for Admins
| Vulnerability | Mitigation |
|---|---|
| Namespace Relabeling | Restrict PATCH permissions on Namespace resources; deny label modifications for tenants |
| Operator Abuse | Audit CREATE permissions on OperatorGroup/Subscription resources; use restrictive RBAC |
| Node Escape | Enforce “Restricted” Pod Security Standards cluster-wide with immutable namespace labels |
| Service Discovery | Implement deny-all Network Policies by default; consider Service Mesh for additional controls |
Follow us for more Updates
