Senior LevelCloud Computing (AWS/GCP/Azure)
How do you enforce Hard Multi-Tenancy in shared Kubernetes clusters across business units?
❓ Interview Prompt: Explain Kubernetes hard multi-tenancy, NetworkPolicies (Cilium), RBAC namespace boundaries, OPA Gatekeeper, and gVisor/Kata sandboxed runtimes.
Running multiple untrusted teams or customer tenants inside a single shared Kubernetes cluster requires enforcing Hard Multi-Tenancy.
The 4 Pillars of Kubernetes Hard Isolation:
1
Control Plane Isolation (RBAC & Namespaces): Strictly scope user and service account permissions to individual namespaces via RBAC 'RoleBindings'.
2
Network Isolation (Cilium / Calico NetworkPolicies): Enforce default-deny egress/ingress network policies preventing inter-namespace pod communication.
3
Resource Starvation Defense: Enforce 'ResourceQuotas' and 'LimitRanges' per namespace to prevent noisy neighbors.
4
Compute Runtime Isolation (gVisor / Kata Containers): Run untrusted tenant pods inside sandboxed container runtimes (gVisor / Kata) to prevent Linux kernel container breakout exploits!
Code Implementation Example
yaml
# Cilium NetworkPolicy enforcing default-deny inter-namespace communication
apiVersion: "cilium.io/2"
kind: CiliumNetworkPolicy
metadata:
name: isolate-tenant-a
namespace: tenant-a
spec:
endpointSelector: {}
ingress:
- fromEndpoints:
- matchLabels:
"k8s:io.kubernetes.pod.namespace": tenant-a # Only allow pods from SAME namespace!
egress:
- toEndpoints:
- matchLabels:
"k8s:io.kubernetes.pod.namespace": tenant-a💡Cilium NetworkPolicy enforcing strict inter-namespace pod isolation.
🎯 Interview Key Takeaway
Hard multi-tenancy in Kubernetes requires namespace RBAC, Cilium default-deny NetworkPolicies, ResourceQuotas, and gVisor sandboxed runtimes.
#Kubernetes#Multi-Tenancy#Cilium#gVisor#Senior
Back to all Cloud Computing (AWS/GCP/Azure) Questions→