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.