Are Kubernetes namespaces a security boundary? Myth vs fact

A namespace is a useful boundary for API objects and for namespace-scoped policy, but on its own it is a weak security boundary. Pods in different namespaces still share nodes, a kernel and, by default, a flat network. How much more you need depends on how much the tenants trust each other.

Myth: a namespace isolates a workload

Fact: a namespace isolates API resources in two ways, per the Kubernetes multi-tenancy docs. Object names can repeat across namespaces, and many policies are namespace-scoped, such as RBAC Roles and NetworkPolicies. Users and service accounts can be restricted to a namespace through RBAC.

That is control plane isolation. It says nothing by itself about the data plane, where pods run.

The RBAC good practices page makes a related point: namespace boundaries are weak, so separate different trust levels into different namespaces and enforce Pod Security standards.

Myth: no policy means no access

Fact: by default, pods can talk to pods in other namespaces. A NetworkPolicy with a default deny is needed, and your network plugin must enforce it. See how to set a default deny NetworkPolicy.

Soft versus hard multi-tenancy

The docs describe hard multi-tenancy as strong isolation, typically when tenants do not trust each other, for example to guard against data exfiltration or denial of service. Soft multi-tenancy is weaker. They call these terms a spectrum, not a binary, and say hardness depends on requirements. They also note data planes have much larger attack surfaces, so hard multi-tenancy needs extra attention there.

Two common cases:

• Multiple teams: shared trust, direct kubectl or GitOps access. RBAC, quotas and network policies do the main work.
• Multiple customers: a vendor runs customer workloads, and customers have no cluster access. Isolation needs to be strong.

What to add to namespaces

For a team cluster, a workable baseline is:

1. One namespace per workload, so each has its own identity and configuration, as the docs recommend.
2. RoleBindings, not ClusterRoleBindings, for team access.
3. Default deny network policies.
4. Pod Security admission at Baseline or Restricted.
5. Resource quotas, so one team cannot starve another.

For untrusting tenants, consider stronger options. The docs say that if sharing is not acceptable, each tenant can get a dedicated cluster, with the cost and management burden weighed against the isolation benefit. Other approaches in the page's contents list, including node isolation, sandboxing and virtual control planes, were not read here, so check them before deciding.

A checklist for shared clusters

Before you put a second team on a cluster, confirm each item: a namespace per workload, RoleBindings scoped to namespaces, default deny network policy, Pod Security labels at Baseline or higher, quotas, and an audit log that records who touched Secrets. Write the result down. If any item cannot be met, say so, and decide whether that team needs its own cluster instead.

Quick check

Sources

• Multi-tenancy, Kubernetes documentation
• RBAC good practices

Last reviewed: 19 October 2026.