Namespace Isolation

Learning objectives

State what a namespace isolates and what it does not.
Apply a ResourceQuota and predict its effect on running workloads.
Explain why quotas belong to namespace creation, not to a checklist.

Namespace ResourceQuota

A namespace is a naming boundary, not a security boundary

A namespace does isolate	A namespace does not isolate
Object names, so two teams can both have a `web` Deployment	Network traffic. Every pod can reach every pod by default
RBAC scope, since Roles are namespaced	Node resources. One namespace can starve another
Quota accounting, once you add a quota	The kernel. Containers still share the node's kernel

Everything in the right-hand column needs something added: a NetworkPolicy, a ResourceQuota, and Pod Security Standards respectively. A namespace on its own buys you naming and RBAC scope, which is useful and is not tenancy.

Adding a quota

yaml

apiVersion: v1
kind: ResourceQuota
metadata: {name: team-frontend-quota, namespace: team-frontend}
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 2Gi
    limits.cpu: "4"
    limits.memory: 4Gi
    pods: "10"

terminal

$kubectl -n team-frontend get resourcequota team-frontend-quota

$kubectl -n team-frontend run greedy --image=busybox --restart=Never --requests=cpu=50,memory=50Gi --dry-run=server -o name

Error from server (Forbidden): ... exceeded quota

A quota constrains future usage, not current

An existing workload inside the limit keeps running untouched, and a workload already over it is not evicted either. The quota only rejects new or updated objects that would exceed it. Applying one to a namespace that is already over budget therefore looks like it did nothing, right up until the next rollout fails.

Quotas belong to namespace creation

A quota you remember to write for each namespace does not scale past a few dozen. Real platforms apply it as part of creating the namespace, so "a namespace exists with no quota" is not a state that can occur. The same applies to default-deny NetworkPolicies and Pod Security labels.

Two teams have separate namespaces with RBAC preventing each from touching the other's objects. Can team A's pods reach team B's database?

RBAC controls who may call the Kubernetes API. It has nothing to do with which pod can open a TCP connection to which, which is what NetworkPolicy is for.

You apply a ResourceQuota to a namespace whose workloads already exceed it. What happens immediately?

Quota is an admission-time control. That makes it safe to introduce, and it also means a quiet cluster afterwards tells you nothing until something tries to deploy.

Why is a namespace not a tenancy boundary for untrusted workloads?

You can add policy, quota and Pod Security Standards to close most of the gap. The shared kernel is the part that needs a sandboxed runtime instead, which is covered later in this module.

Recap

A namespace isolates names and RBAC scope, not traffic, resources or the kernel. Add a quota, a default-deny policy and Pod Security labels, and apply them at namespace creation rather than from a checklist. Next: the policies themselves.