Multi-Tenancy Models

## What a namespace is, and what it is not A **namespace** is a name scope inside one Kubernetes cluster. Two teams can each own a Deployment called `api` in namespaces `invoices` and `payroll` without a collision. Several policy objects are **namespaced** as well, so the namespace is the natural unit to attach them to. A namespace **enforces nothing by itself**. A freshly created namespace has no permission fence beyond what existing bindings grant, no resource ceiling and no network wall. By default a pod in `invoices` can open a connection to any pod in `payroll`, because the pod network is flat. People confuse the *label on the door* with the *lock*. Interviewers probe exactly that confusion. ## Soft multi-tenancy **Soft multi-tenancy** assumes tenants are **mostly trusted**, for example product teams in the same company. The goal is to prevent accidents, privilege creep and noisy neighbours, not to stop a determined attacker. Each tenant gets a namespace plus a standard bundle: - **RBAC**: namespace-scoped bindings, so the team manages only its own objects. - **`ResourceQuota`**: a ceiling on the total requests, limits and object counts the namespace can consume. - **`LimitRange`**: default and bounded requests and limits per container, so unset pods still count against quota sensibly. - **Default-deny `NetworkPolicy`**: traffic is blocked unless explicitly allowed. This works only if the CNI plugin enforces NetworkPolicy. - **Pod Security Admission labels**: `pod-security.kubernetes.io/enforce` on the namespace pins the Pod Security Standard its pods must meet. It is cheap. The tenants share one control plane, one pool of nodes, one upgrade and one set of add-ons. ## Hard multi-tenancy **Hard multi-tenancy** assumes a tenant **may be hostile**: customers running their own code, or a workload such as a PDF-invoice renderer that parses untrusted uploads. The boundary must hold even if a tenant escapes its container or abuses the API. That forces you to separate the things a namespace leaves shared: - a **cluster per tenant**: a separate control plane, nodes and cluster-scoped objects - **dedicated, tainted node pools** per tenant, often with a sandboxed container runtime selected through a `RuntimeClass`. This removes kernel sharing between tenants but keeps the API server shared, so many engineers call it a stronger form of soft tenancy rather than fully hard. ## What stays shared inside one cluster | Shared surface | Why it matters | Does the namespace bundle close it? | |---|---|---| | Node kernel | A container escape or kernel bug reaches every pod on that node | No | | Nodes and kubelet | Disk, PID and network contention. A node's credential can read Secrets of the pods bound to it | Partly: quota caps totals, not who lands beside you | | Cluster-scoped objects | CRDs, ClusterRoles, StorageClasses, PriorityClasses, webhook configurations, Nodes, PersistentVolumes | No | | Control plane | One API server and one etcd. A tenant's list storm or a pile of 612 CRDs costs everyone | No. API Priority and Fairness softens it | | Cluster DNS | Any pod can resolve `<svc>.<ns>.svc.cluster.local` for any namespace | No. NetworkPolicy filters traffic, not name lookups | ## How to choose 1. **Who writes the code that runs?** Your own engineers point to soft. Customers or untrusted input point to hard. 2. **What does one breach cost?** Regulatory or contractual isolation requirements usually settle it. 3. **Do tenants need cluster-scoped control?** Their own CRD versions, admission webhooks or cluster-admin access cannot be granted per namespace. 4. **Can you run the fleet?** Each extra cluster multiplies upgrades, add-ons and idle capacity. ## The interview trap The weak answer is "put each tenant in its own namespace and it is isolated". The strong answer names the bundle that makes a namespace a *soft* boundary, and names the kernel, nodes, control plane and cluster-scoped objects as the reasons it can never be a *hard* one.