Sources & further reading

References

The documentation, security guidance and background material behind each shared risk and hardening technique covered in the talk.

Shared risks

Every tenant talks to the same API server, and it hosts cluster-scoped machinery they all share.

Highly privileged operators and node-wide DaemonSets are confused deputies waiting to be abused.

RBAC complexities can make Multi-Tenancy a lot harder.

One flat LAN by default — and the API server turns tenant-to-tenant reachability into SSRF by design.

Tenants share the node and its kernel — so a container breakout puts every workload on that node at risk.

One shared registry means one poisoned push can reach every tenant that pulls the image.

Decide what tenant workloads are allowed to look like, closing off the easy routes from a pod spec to the node.

Keep tenant rights narrow, watch for the dangerous verbs, and treat every operator as part of the tenant's effective privilege.

Turn the flat cluster network into something tenants can't freely cross, and close the shared paths network policy can't see.

Place tenants on dedicated groups of nodes to remove the shared kernel and reduce the blast radius of a node compromise.

Stop relying on the shared Linux kernel as the tenant boundary, using gVisor or VM-based runtimes like Kata Containers.

Give each tenant their own API server on a shared host cluster, removing most of the cluster-scoped sharing problems.

Sometimes the best way to share a cluster is not to. Separate clusters remove most of the shared surfaces at once.