Reducing the risk
Hardening
A shared Kubernetes cluster has unavoidable trust relationships, but careful design can reduce their reach and limit the damage when a boundary fails.
There is no single switch that makes a Kubernetes cluster safe for mutually untrusted tenants. Hardening is a set of layered controls: reduce what tenants share, constrain the access they receive, and limit the blast radius when one control fails.
These techniques address different parts of that problem. Their value depends on your tenancy model, so start with the rights tenants hold and the degree of trust between them.
They’re roughly ordered from the controls every shared cluster should have, through to the more expensive ones you’ll want as trust between tenants drops, ending with the option of not sharing a cluster at all.
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.