skip to content

When onboarding a team into a shared Kubernetes cluster as a namespace tenant, which objects make up the tenant bundle and what does each isolate?

level: middleimportance: should knowfreq 55%

answer

  1. a namespace plus five objects
  2. who, how much, how big
  3. who connects, what pods may do
  4. labels live on the Namespace
  5. tenant must not edit its fence

basics

~10 s

A tenant namespace needs RBAC bindings (who can act), a ResourceQuota (how much in total), a LimitRange (per-container defaults), a default-deny NetworkPolicy (who can connect) and Pod Security Admission labels (what pods may do).

solid answer

~40 s

The namespace is just the container. The isolation comes from five objects applied together, usually from one template. A **RoleBinding** gives the team rights only inside its namespace. A **`ResourceQuota`** caps what the team consumes in total, so one team cannot starve the shared nodes. A **`LimitRange`** injects default requests and limits, so pods that omit them still count against the quota. A **default-deny `NetworkPolicy`** closes the flat pod network, and later policies allow only intended traffic. **Pod Security Admission labels** such as `pod-security.kubernetes.io/enforce: restricted` stop privileged or host-namespace pods. The team must not be able to edit its own Namespace object, because the labels live there. Leave out any one piece and the fence has a gap.

code

yaml · 25 lines
yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
  namespace: invoices
spec:
  hard:
    requests.cpu: "37"
    requests.memory: 74Gi
    limits.memory: 111Gi
    pods: "143"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: tenant-defaults
  namespace: invoices
spec:
  limits:
  - type: Container
    defaultRequest:
      cpu: 250m
      memory: 384Mi
    default:
      memory: 768Mi

go deeper

for a junior

Know that a tenant namespace needs more than the namespace itself: permissions, a resource cap and a network wall.

for a middle

Name all five objects and say in one line what each isolates and what breaks if it is missing.

for a senior

Show how you stop tenants editing their own fence: no write on quotas, limits or policies, and no write on the Namespace object.

for a principal

Treat the bundle as a versioned platform template with drift detection, and be clear it gives soft isolation only.

## Why a bundle and not a namespace In Kubernetes a **namespace** gives a team a private set of object names. It limits nothing. Onboarding a tenant into a shared cluster therefore means creating the namespace **and** a set of namespaced policy objects that turn it into a soft boundary. Platform teams usually stamp these out from one template, so every tenant gets the same fence and nobody forgets a piece. This answer covers what each piece isolates. The detailed mechanics of each object belong to their own topics. ## The five pieces | Object | Question it answers | Gap if missing | |---|---|---| | RoleBinding (to a Role or ClusterRole) | Who may do what in this namespace? | The team either cannot work or gets rights beyond its namespace | | `ResourceQuota` | How much can this tenant consume in total? | One tenant's runaway rollout starves the shared nodes | | `LimitRange` | What does a pod get if it declares nothing? | Pods without requests are rejected under quota or run unbounded | | Default-deny `NetworkPolicy` | Who may connect to or from these pods? | Any pod in the cluster can reach the tenant's pods | | Pod Security Admission labels | What kind of pod may run here? | Privileged or `hostPath` pods can reach into the node | More detail on each: - **RBAC** scopes the *API* boundary. A namespaced RoleBinding grants rights only inside `invoices`, even when it references a reusable ClusterRole. - **`ResourceQuota`** scopes *aggregate consumption*: total CPU and memory requests and limits, pod counts, storage claims. - **`LimitRange`** scopes *per-object sizing*. It fills in defaults at admission and rejects containers outside its min/max bounds. - **Default-deny `NetworkPolicy`** scopes *traffic*. It needs a CNI plugin that enforces policy, and it usually comes with a companion policy that allows DNS egress. - **Pod Security Admission labels** scope *privilege*, by pinning a Pod Security Standard level on the namespace. ## A tenant template ```yaml apiVersion: v1 kind: Namespace metadata: name: invoices labels: pod-security.kubernetes.io/enforce: restricted --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny namespace: invoices spec: podSelector: {} policyTypes: - Ingress - Egress ``` The `ResourceQuota`, `LimitRange` and RoleBinding sit in the same template, sized per tenant. ## Keeping the tenant inside the fence The bundle holds only if the tenant cannot rewrite it: 1. **The Namespace object is cluster-scoped.** Editing its labels needs a cluster-level grant. A tenant who holds one could lower its own Pod Security level, so tenants should not have it. 2. **Policy objects are namespaced**, so the team's role should exclude write access to `resourcequotas`, `limitranges` and usually `networkpolicies`. Otherwise the team can raise its own ceiling or open its own wall. 3. **Cluster-wide rights stay with the platform.** A tenant with a ClusterRoleBinding to a broad role has left the fence entirely. 4. **Drift is checked.** A GitOps controller or a policy engine re-applies or audits the template, so manual edits do not quietly widen a tenant. ## What the bundle still does not isolate Even perfectly applied, the bundle leaves tenants sharing: - the **node kernel**, and the nodes themselves - the **API server and etcd** - **cluster-scoped objects** such as CRDs, StorageClasses and ClusterRoles - **cluster DNS**: names in other namespaces still resolve, and only traffic is blocked That is why the bundle is called **soft** multi-tenancy. It is right for trusted teams. Untrusted code needs dedicated nodes or clusters on top. ## Interview shape A good answer lists all five pieces, says in one line what each isolates, and adds that the tenant must not control its own fence. A weak answer stops at "create a namespace and a RoleBinding", which leaves the quota, the network and pod privilege wide open.

  • Why should a tenant team not be able to patch its own Kubernetes Namespace object?
    The Pod Security Admission level is stored as labels on the Namespace, and platform tooling often keys policies off namespace labels too. A tenant who can patch them can relax its own pod restrictions or slip into another policy's selector. Namespaces are cluster-scoped, so simply not granting that cluster-level write keeps the fence intact.
  • A team's pods in a freshly fenced Kubernetes namespace cannot resolve any Service names. Which bundle piece caused it?
    The default-deny NetworkPolicy. Its Egress policy type also blocks traffic to the cluster DNS pods, so the template needs a companion policy that allows egress to the DNS service on port 53 over UDP and TCP. Add it to the template, not per tenant.

saying these in an interview costs you the question

  • Creating a namespace and a RoleBinding is enough to fence a tenant.
  • A LimitRange caps a namespace's total resource consumption.
  • Giving the team edit rights on its Namespace object is harmless.
  • A NetworkPolicy works on every cluster regardless of CNI plugin.
  • The bundle isolates the node kernel between tenants.