Kubernetes Namespace Boundary Model

Kubernetes Namespace Boundary Model is the composite security and governance boundary that emerges once RBAC, NetworkPolicy, ResourceQuota, and Pod Security Admission are all deliberately layered together around a namespace, as distinct from the bare namespace object, which provides no such boundary on its own. This composite model — often called "soft multi-tenancy" — represents the practical ceiling of isolation achievable through namespace-based separation alone, and understanding both what it achieves and where it still falls short of true hard isolation is essential for making an informed decision about whether namespace-based separation is sufficient for a given trust boundary, or whether separate clusters are actually required.

The model is "composite" specifically because no single Kubernetes mechanism provides the full boundary on its own — each piece closes off one specific dimension of potential cross-namespace interaction, and the boundary is only as strong as the weakest dimension left unaddressed.

The Four Layers of the Composite Boundary

RBAC: Controlling API Access

Role and RoleBinding objects scoped to a namespace restrict which users and service accounts may read or modify resources within it, forming the access-control dimension of the boundary — without this layer, any authenticated user with broad permissions can freely act across every namespace regardless of any other isolation measure in place.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: codartium-team-access
  namespace: codartium-team
subjects:
  - kind: Group
    name: codartium-team-members
roleRef:
  kind: ClusterRole
  name: edit

NetworkPolicy: Controlling Network Reachability

Default-deny NetworkPolicy rules restrict which Pods, in which namespaces, may establish network connections to Pods within the boundary, closing the network dimension that is otherwise entirely open by default.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: codartium-default-deny
  namespace: codartium-team
spec:
  podSelector: {}
  policyTypes: ["Ingress"]

ResourceQuota: Controlling Resource Consumption

Bounding aggregate CPU, memory, and object counts prevents one namespace's workloads from starving shared cluster capacity that other namespaces also depend on, closing the resource-fairness dimension.

Pod Security Admission: Controlling Container Privilege

pod-security.kubernetes.io/enforce labels restrict how privileged containers within the namespace are permitted to be, closing the container-escape and host-access dimension that RBAC, network policy, and quota do not address at all.

metadata:
  labels:
    pod-security.kubernetes.io/enforce: restricted

What This Composite Model Achieves

Effective Soft Multi-Tenancy

Together, these four layers produce a meaningfully strong boundary suitable for separating workloads and teams that trust the platform and each other to a reasonable degree, but do not need to trust each other's code directly — internal teams within a single organization sharing a cluster is the canonical fit for this model.

Auditable, Enforceable Governance

Because each layer is independently configurable, verifiable, and auditable (via kubectl get rolebindings, kubectl get networkpolicy, kubectl describe resourcequota, and namespace label inspection), the composite boundary is one that can be systematically reviewed and confirmed to be in place, rather than relying on informal convention alone.

Where the Model Still Falls Short

Shared Kernel and Container Runtime

Every namespace in a standard cluster still shares the same underlying node kernel and container runtime — a kernel-level vulnerability or container escape exploit is not contained by any of the four layers above, since none of them address the shared-kernel attack surface directly; only a hardened runtime (RuntimeClass with gVisor or Kata Containers) or genuinely separate clusters close this gap.

Shared Control Plane

The Kubernetes API server, etcd, and scheduler are shared across every namespace in a cluster — a control-plane-level compromise or a sufficiently privileged credential leak bypasses every namespace-level boundary simultaneously, since these boundaries are enforced by the control plane, not independent of it.

Noisy-Neighbor Effects Beyond CPU/Memory

As covered in resource management boundary considerations, ResourceQuota does not protect against I/O, memory bandwidth, or network contention between namespaces sharing the same physical nodes — the resource-fairness layer of this model is narrower than it might first appear.

Deciding Between Soft and Hard Multi-Tenancy

The composite namespace boundary model is appropriate when workloads trust the platform and broadly trust each other, even if they should not have direct access to each other's resources — genuinely adversarial or fully untrusted workloads (external customer code, in a SaaS platform running customer workloads directly) generally warrant hard multi-tenancy: separate clusters, or at minimum, hardened sandboxed runtimes on top of the full composite model described here.

Example

apiVersion: v1
kind: Namespace
metadata:
  name: codartium-boundary-model-example
  labels:
    team: codartium
    pod-security.kubernetes.io/enforce: restricted
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: codartium-quota
  namespace: codartium-boundary-model-example
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"