Kubernetes tenant isolation: evaluate namespaces as part of a wider boundary

Sources checked: 29 October 2026. This article contains FailSafe's analysis and proposed validation workflow; linked sources support the reported facts.

A Kubernetes tenant-isolation assessment should connect namespace organization to workload identity, network access, storage, and cluster permissions. A namespace label alone cannot explain whether two workloads are isolated under the organization's chosen threat model.

Kubernetes describes multiple controls and tradeoffs involved in sharing clusters among tenants. Kubernetes multi-tenancy documentation provides the underlying reference. The assessment design below is an original defensive example, not a report of a customer incident.

Define who shares the cluster

List tenants, application teams, cluster administrators, workloads, and the resources each is expected to access. Determine whether tenants trust one another and whether cluster administration belongs to an internal platform team or an external operator. Record namespace, network, storage, identity, and admission boundaries relevant to the selected workload. An assessment of application isolation has a different objective from an attempt to escape a container. State which objective is authorized, and identify provider-managed components that remain outside the engagement.

Build a synthetic two-workload scenario

Use a dedicated test cluster or approved staging namespaces with harmless services and test data. Give each workload its intended service identity and explicitly permitted dependencies. Demonstrate normal communication, then evaluate an owner-approved denied interaction between the two workloads. Keep the test limited to known resources and low traffic. Do not retrieve real cluster secrets, deploy privileged workloads, or attempt host access without separate authorization. The scenario should show a specific policy decision rather than rely on broad cluster enumeration.

Capture policy and runtime context

Preserve sanitized namespace and workload references, service identities, relevant policy versions, requested action, and observed result. Correlate application behavior with owner-provided control-plane or network records when available. A network timeout may be caused by an unavailable service, so include a legitimate connectivity control. A policy object existing in the cluster does not prove it is enforced for the tested traffic. State whether the evidence comes from runtime behavior, configuration review, or both, and describe uncertain results without inflating them into a cluster compromise.

Retest changes and cluster assumptions

Repeat the denied and allowed interaction after changes, including rescheduled workloads if identity or policy attachment depends on deployment. Confirm synthetic resources are removed. Document excluded nodes, namespaces, storage classes, and cluster administration paths. Passing one workload case does not establish all tenant isolation. For recurring agentic assessment, use an explicit cluster and namespace allowlist, bounded permissions, and an operations contact. Specialist container-escape or host-level research should be scoped independently with its own risk controls and disclosure plan.

A useful assessment artifact

Create a workload-boundary table covering identity, namespace, network destinations, storage, and administrative ownership. Mark controls verified through behavior separately from controls inspected in configuration. It lets readers understand the chosen isolation model without assuming that every cluster shares the same threat model.

Plan an assessment

Discuss the authorized scope and required evidence with FailSafe SWARM. For a business evaluating an initial engagement, review the first-pentest offer and confirm scope before purchase.