Key takeaway: Two workloads in different namespaces can reach each other over the network, exhaust shared node resources, and be modified by a role that was never scoped correctly, all by default. Isolation is something you build, not something namespaces provide automatically.
What a Namespace Actually Does
A namespace is a logical grouping and a naming scope. Objects within it can share a name without colliding with identically named objects elsewhere, and RBAC roles can be scoped to it. That is the extent of what a bare namespace enforces on its own.
Networking, by default, ignores namespace boundaries entirely — a pod in one namespace can reach a pod in another over the cluster network unless something explicitly prevents it. Resource consumption similarly has no default limit — a workload in one namespace can consume node resources that starve workloads in another, unless quotas are configured. Assuming namespace separation implies workload isolation is a common and consequential misunderstanding.
The Layers That Actually Provide Isolation
| Layer | What it restricts | Default state |
|---|---|---|
| Namespace | Naming and RBAC scope | Enabled, minimal enforcement |
| NetworkPolicy | Which pods can reach which | Unrestricted unless configured |
| ResourceQuota | Total resource consumption per namespace | Unlimited unless configured |
| LimitRange | Per-pod resource defaults and bounds | Unlimited unless configured |
| RBAC RoleBinding | Who can act on resources in the namespace | Must be explicitly scoped |
Each of these has to be deliberately configured for a namespace to function as a genuine tenant boundary. Skipping any one leaves a gap — a namespace with network policy and resource quotas but a RoleBinding accidentally granted at the cluster scope still permits access the tenant model assumed was restricted.
Where This Goes Wrong in Practice
The most common failure is assuming network isolation exists because namespaces exist, without ever applying a NetworkPolicy. Every pod can reach every other pod across the entire cluster by default, across namespace boundaries, which means a compromised low-trust workload can reach a high-trust one directly unless network policy specifically prevents it.
The second common failure is a shared default namespace where quotas were never configured, so a runaway process or a misconfigured job in one “tenant” consumes cluster-wide node capacity that a differently-scoped tenant needed, with no configured limit having prevented it.
Building Genuine Isolation
Apply a default-deny NetworkPolicy per namespace as the starting point, then explicitly allow only the specific communication paths a workload genuinely needs. Default-deny is the safer posture because it fails toward restriction rather than toward openness when something is misconfigured or forgotten.
Set both ResourceQuota and LimitRange for every tenant namespace, so no single workload can consume disproportionate cluster capacity and every pod has sensible default resource bounds even when its own specification omits them.
Scope every RoleBinding to the namespace explicitly and audit for any ClusterRoleBinding that grants access more broadly than intended — a single accidentally cluster-scoped binding undermines every other isolation control built for that namespace.
When Namespace-Level Isolation Is Not Enough
For genuinely adversarial multi-tenancy — untrusted external customers running arbitrary workloads — namespace-level isolation with these controls is frequently still insufficient, and separate clusters or a virtualisation layer between tenants becomes the safer architecture. Namespace-based isolation is appropriate for internal teams operating in good faith; it is a weaker guarantee than genuinely adversarial tenancy requires.
The Bottom Line
Treat a bare namespace as providing naming convenience and nothing else. Build actual isolation deliberately with default-deny network policy, resource quotas and limit ranges, and carefully scoped RBAC, and recognise that genuinely adversarial multi-tenancy likely needs stronger boundaries than namespaces can provide at all.
