Namespaces and tenant boundaries · Kubernetes Handbook

The mechanism

Namespaces organize namespaced objects and provide a scope for many policies. They are useful for separating teams and workloads, but they are not by themselves a strong security boundary against every hostile tenant. Nodes, control-plane components and cluster-scoped resources remain shared.

A tenant design combines identity, RBAC, admission, network policy, resource quotas, storage policy and runtime constraints. The appropriate boundary depends on the trust relationship and the damage a tenant could cause. Some workloads require stronger separation than a shared namespace model can provide.

For ParcelOps, two fictional teams can have independent object names and grants. Their caches, credentials and application data still need tenant-aware authorization. Kubernetes namespace separation does not automatically fix an application that returns another tenant’s records.

Tenant identity

Namespace policies

Shared infrastructure

Application data boundary

Worked example

This tenant review table is a planning artifact. It deliberately leaves runtime and infrastructure decisions open rather than claiming a universal multi-tenant architecture.

API objects: namespace-scoped RBAC
Network: enforced ingress and egress policy
Resources: reviewed quotas and requests
Workload privilege: admission and runtime restrictions
Storage: tenant-aware provisioning and access
Application records: independent object authorization
Shared nodes/control plane: trust and isolation decision required

Practice: predict, inspect, explain

Offline exercise. Consider a trusted internal team, an untrusted customer workload and a privileged infrastructure agent. Compare their required boundaries. Identify which resources are cluster-scoped and which authority would let one tenant affect another.

Expected observation: one namespace-per-tenant is an organizational starting point, not a complete threat model. Write a negative test for API access, network access and application data access separately. Keep the stronger-isolation decision tied to concrete requirements and provider capabilities.

Troubleshooting and trade-offs

If one tenant exhausts shared capacity, inspect quotas, requests and platform reservations. If network isolation fails, inspect actual policy enforcement. If a tenant can administer cluster-scoped resources, review the trust model. Do not market namespace separation as hard isolation without evidence covering the relevant threat and shared components.

Interview practice

What does a namespace provide?

A naming and policy scope for namespaced resources. Strong tenant isolation requires additional controls and sometimes separate infrastructure.

Why test application data separately?

Cluster controls cannot correct an application authorization bug that returns another tenant’s records through an otherwise permitted service.

Completion check

Choose a boundary for three tenant trust levels and justify the remaining shared risks.

Sources and version notes

Baseline checked 6 October 2026: the official release page lists Kubernetes 1.37.1. Verify your cluster and distribution prerequisites. All manifests are offline teaching examples; no cluster mutations or cloud resources are executed by this handbook.

YOUR NEXT STEP

Make the understanding yours.

Use the completion check above. Mark this chapter when you can explain the mechanism and its limits.

Self-assessed reading progress. This does not certify that a lab ran or a system is secure.