Isolate tenants in a shared Kubernetes cluster

WHAT THIS TESTS This checks whether you understand that Kubernetes multi-tenancy is defense in depth across several primitives, and that a namespace is a soft, not hard, boundary on a shared kernel and control plane.

A GOOD ANSWER COVERS Start with one namespace per tenant as the unit of policy. Apply a ResourceQuota per namespace to cap total requested and limited CPU, memory, and object counts so no tenant exhausts the cluster. Pair it with a LimitRange to set per-pod defaults and maximums, because a quota on limits requires every pod to declare them. Apply RBAC roles bound within each namespace so a tenant cannot read or modify other namespaces. Enforce NetworkPolicies with default-deny ingress and egress per namespace, then allow only the traffic each tenant needs; this requires a policy-capable CNI such as Calico or Cilium. For stronger isolation add dedicated node pools or a sandbox runtime like gVisor for sensitive tenants.

COMMON WRONG ANSWERS Claiming namespaces alone provide security isolation; they share the kernel, so a container escape crosses tenants. Forgetting LimitRanges, so quotas on limits silently reject pods that omit them. Assuming NetworkPolicies work without a policy-capable CNI. Ignoring control-plane noisy neighbors such as API server or etcd abuse.

LIKELY FOLLOW-UPS How do you stop API server abuse by one tenant? When do you move to virtual clusters or fully separate clusters? How do PriorityClasses interact with quotas? How do you isolate shared DNS?

ONE CONCRETE EXAMPLE Tenant A gets namespace tenant-a with a quota of 20 CPU and 40Gi, a LimitRange defaulting pods to 500m CPU, RBAC limited to that namespace, and a default-deny NetworkPolicy that allows ingress only from its own pods and egress only to a shared logging service. Tenant B gets an identical, isolated set, so neither can starve the cluster nor reach the other's services.