Isolate tenants in a shared Kubernetes cluster
layered multi-tenancy.
namespaces as the boundary, ResourceQuotas plus LimitRanges to cap compute, default-deny NetworkPolicies for traffic, and RBAC per namespace.
treating a namespace alone as a hard security boundary.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
Why might a ResourceQuota that caps total CPU limits silently reject otherwise valid pods in a tenant namespace?
- a.Pods that omit CPU limits violate the quota unless a LimitRange supplies defaultsCorrect
- b.The CNI plugin must approve each pod's resources
- c.NetworkPolicies override quota enforcement
- d.Namespaces cannot enforce quotas without RBAC
Why? this is the answer
A quota on limits requires every pod to declare limits; without a LimitRange providing defaults, undeclared pods are rejected. RBAC and the CNI govern access and networking, not whether resource requests satisfy a quota.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #multi-tenancy
- #networkpolicy
- #resourcequota
- #isolation
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles