Kubernetes security talk companion
Kubernetes Multi-Tenant Blues
Putting everyone on one cluster saves money and reduces complexity — until the tenants stop trusting each other. This site collects the detail and references behind the talk on where shared clusters go wrong.
Designed for sharing, not for distrust
Kubernetes was designed for running many applications on shared infrastructure. It was not designed for tenants that don't trust each other. Multi-tenancy asks the platform to do something it was never built to do — and that gap is where the risk lives.
Sharing is risk
The shared surfaces
Every tenant on a cluster ends up sharing the same surfaces. Each one is a place where the boundary between tenants can break down. These are the ones the talk digs into.
API Server
Every tenant talks to the same API server, and it hosts cluster-scoped machinery they all share.
02Operators & DaemonSets
Highly privileged operators and node-wide DaemonSets are confused deputies waiting to be abused.
03RBAC
RBAC complexities can make Multi-Tenancy a lot harder.
04Networking
One flat LAN by default — and the API server turns tenant-to-tenant reachability into SSRF by design.
05Nodes
Tenants share the node and its kernel — so a container breakout puts every workload on that node at risk.
06Container Registries
One shared registry means one poisoned push can reach every tenant that pulls the image.
Hardening
Reduce the blast radius
Layered controls can reduce what tenants share and limit the damage when a boundary fails. Explore practical techniques for hardening a multi-tenant cluster.
Admission Control
Decide what tenant workloads are allowed to look like, closing off the easy routes from a pod spec to the node.
02RBAC & Operator Hygiene
Keep tenant rights narrow, watch for the dangerous verbs, and treat every operator as part of the tenant's effective privilege.
03Network Isolation
Turn the flat cluster network into something tenants can't freely cross, and close the shared paths network policy can't see.
04Node Pools
Place tenants on dedicated groups of nodes to remove the shared kernel and reduce the blast radius of a node compromise.
05Sandboxed Runtimes
Stop relying on the shared Linux kernel as the tenant boundary, using gVisor or VM-based runtimes like Kata Containers.
06Virtual Clusters
Give each tenant their own API server on a shared host cluster, removing most of the cluster-scoped sharing problems.
07Separate Clusters
Sometimes the best way to share a cluster is not to. Separate clusters remove most of the shared surfaces at once.