The core of the talk
Sharing Is Risk
Sharing is caring — but on a Kubernetes cluster, sharing is also risk. Every surface that tenants share is a place where the boundary between them can fail.
We’ve all heard the idea that “Sharing is caring” before, but in multi-tenancy security, sharing isn’t caring, sharing is risk.
Any resource that’s shared between tenants presents an attack surface where a hostile tenant might try to gain unauthorised access to another tenant’s applications, or abuse shared resources to impact the availability of another tenant’s services.
Part of the reason this is tricky is that a lot of Kubernetes multi-tenancy leans on namespaces, and namespaces were originally designed as a way of organising resources, not as a security boundary. Security controls like RBAC, network policy and Pod Security Admission were layered on top later, and plenty of the software we install into clusters was written without multi-tenancy in mind at all.
In Kubernetes there are quite a few different shared resources that attackers might try to target.
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.