Design a secure multi-tenant CI/CD runner on Kubernetes
Hard multi-tenancy for untrusted CI.
Apply namespaces, NetworkPolicies, Pod Security Standards; cap resources with ResourceQuotas and LimitRanges; schedule to dedicated or sandboxed nodes.
Labels or RBAC alone suffice.
What's really being asked
This question evaluates whether you can design a hard multi-tenant Kubernetes environment for inherently untrusted CI workloads. Interviewers want to see layered defense covering cluster-level controls, node-level boundaries, and runtime sandboxing. They also care about operational fairness and cost control when multiple teams share compute.
The full answer
Four layers in order. First, namespace isolation with strict NetworkPolicies that default-deny cross-tenant traffic and only allow egress to required registries and artifact stores. Second, Pod Security Standards enforcing restricted profiles via Pod Security Admission so builds cannot run privileged containers or mount host paths. Third, resource governance using per-namespace ResourceQuotas for aggregate CPU and memory and LimitRanges to set default and max requests per pod, preventing one team from exhausting cluster capacity. Fourth, node-level separation using taints and tolerations or dedicated node pools so sensitive tenants do not share kernels with arbitrary build code, supplemented by sandboxed runtimes like gVisor or Kata Containers where supply-chain risk is high.
The mistakes people make
Red flags include relying solely on RBAC and labels for isolation, since compromised pods bypass both. Another mistake is omitting LimitRanges, which allows a single build pod to request 64 cores and starve neighbors. Suggesting privileged sidecars for Docker-in-Docker without mentioning rootless or sandboxed alternatives is also dangerous. Finally, ignoring admission control means tenants can accidentally or maliciously violate security policies.
What usually comes next
How would you handle image pull secrets without leaking them across namespaces? What happens when a tenant legitimately needs privileged builds for kernel module compilation? How do you charge back cloud costs per team? Would you use virtual clusters or cluster-per-tenant instead, and at what fleet size?
A concrete example
A platform team runs GitLab CI on a 200-node EKS cluster. Each engineering team gets a namespace with a ResourceQuota of 100 CPU and 200 Gi memory and a LimitRange capping any single pod at 8 CPU. NetworkPolicies block all ingress and only allow egress to Artifactory and AWS APIs. Build pods land on a dedicated node pool tainted ci-workloads via tolerations, and pods from external contractors additionally use Kata Containers. Pod Security Admission rejects any pod requesting hostNetwork or runAsRoot. This setup prevented a crypto-mining build from escaping its namespace and capped blast radius during a supply-chain incident last quarter.
Interview question
When designing a hard multi-tenant Kubernetes environment for untrusted CI runners, which control combination both prevents cross-tenant network access and mitigates kernel-level compromise?
- a.ResourceQuotas, LimitRanges, and privileged build pods with hostPath mounts for layer caching
- b.Default-deny NetworkPolicies, Pod Security Standards, ResourceQuotas with LimitRanges, and sandboxed or dedicated node poolsCorrect
- c.Pod Security Admission, shared node pools, and namespace isolation without egress restrictions
- d.Namespace-scoped RBAC, node labels per team, and cluster-wide egress allow rules
Why? this is the answer
Option B covers all four required layers—network isolation, runtime restriction, resource governance, and node-level boundaries. Option D is the most tempting distractor because RBAC and node labels are bypassed by compromised pods and provide neither default-deny network controls nor kernel sandboxing.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #multi-tenancy
- #ci/cd
- #security
- #resource-management
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