auditing-namespace-as-tenant-boundary

name	auditing-namespace-as-tenant-boundary
description	Audit a Kubernetes namespace that is treated as a tenant isolation boundary for the isolation it does not actually provide: cluster-scoped resources and nodes shared across namespaces, RBAC that grants a tenant reach beyond its own namespace, missing network policy so pods cross namespaces freely, and shared cluster services (DNS, ingress, admission, storage classes) that see or serve every tenant. Covers multi-tenant clusters where each tenant is given a namespace and the namespace is assumed to contain them. Use when a namespace is the unit of tenant separation and the assumption is that a tenant cannot affect or observe another. The tenant confined to a namespace is the source, the cross-tenant resource or namespace it reaches is the sink, and the isolation the namespace does not enforce is the bug.
license	MIT

Auditing the namespace as a tenant boundary: what a namespace does not isolate

A namespace is a name-scoping and policy-attachment unit, not a security sandbox, yet multi-tenant clusters routinely hand each tenant a namespace and assume it contains them. It does not, on its own. Nodes are shared, so a tenant that can influence scheduling or escape a container reaches another tenant's pods on the same node. Cluster-scoped resources, custom resource definitions, node objects, persistent volumes, and cluster roles sit outside every namespace and are visible or reachable across them. RBAC that grants a verb at cluster scope, or on another namespace, punches straight through the boundary. Without network policy, pods cross namespaces freely. And the shared cluster services every tenant depends on, DNS, ingress, admission, storage classes, see or serve all tenants at once. The audit question is not whether tenants have separate namespaces but whether the namespace actually stops one from affecting or observing another. You audit this by testing each isolation the boundary is assumed to provide.

When to use

• A namespace is the unit of tenant separation and is assumed to isolate one tenant from another.
• Tenants share nodes, cluster-scoped resources, and cluster services (DNS, ingress, admission, storage).
• RBAC, network policy, or resource quotas may not fully confine a tenant to its own namespace.

Scope check

Audit tenant isolation only on clusters you own or are authorized to assess, on non-production tenants. Testing cross-tenant reach touches other namespaces' resources, so use non-production tenants and do not read or alter another tenant's real data. If you can't name the authorization, stop.

The loop

1. Establish what the boundary must isolate first. Name what one tenant must not be able to do to another: read its resources, reach its pods, exhaust shared capacity, observe its traffic. This is the false-positive killer: a namespace backed by tenant-scoped RBAC, a default-deny network policy, resource quotas, and no cross-namespace or cluster-scoped grants is enforcing the boundary. Name the required isolations, then test each.

2. Audit RBAC reach beyond the namespace. For each tenant's identities, enumerate whether any binding grants a verb at cluster scope or on another namespace: cluster roles, cross-namespace role bindings, or access to cluster-scoped resources. A single cluster-scoped grant lets a tenant read or act outside its namespace, breaking the boundary at the API layer.

3. Check network isolation between namespaces. Determine whether pods in one tenant namespace can reach pods and services in another. Without a default-deny network policy, namespaces do not isolate traffic, so one tenant reaches another's services directly. Confirm segmentation exists between tenant namespaces, not just within one.

4. Find shared-resource and node exposure. Identify the cluster-scoped resources and nodes tenants share: node objects, persistent volumes and storage classes, custom resource definitions, and node co-tenancy. A tenant that can view or influence these, or that shares a node with another tenant's pods, reaches across the boundary through the shared layer rather than the API.

5. Check shared cluster services and quotas. Confirm the shared services every tenant uses, DNS, ingress, admission webhooks, do not leak one tenant's data to another or let one tenant's configuration affect another, and that resource quotas prevent one tenant from exhausting capacity and denying service to the rest. A shared service that serves all tenants without isolation, or missing quotas, is a cross-tenant effect.

6. Confirm and record. Confirm by acting as one tenant to read another tenant's resource, reach another's pod, or exhaust a shared resource, across non-production tenants and without touching real data. Kill the lead if tenant RBAC is namespace-scoped with no cluster-scoped or cross-namespace grants, default-deny network policy separates tenants, quotas bound each tenant, and shared services do not leak across tenants. Record the tenant source, the cross-tenant resource or namespace sink, and the isolation the namespace did not enforce.

Where the namespace boundary leaks

• Cluster-scoped grants punch through. A cluster role or cross-namespace binding lets a tenant read or act outside its namespace at the API layer.
• No network policy means namespaces are not isolated. Without a default-deny, pods in one tenant namespace reach another's services directly.
• Shared nodes host multiple tenants. Node co-tenancy plus a container escape reaches another tenant's pods on the same node.
• Cluster-scoped resources are visible across tenants. Node objects, volumes, and custom resource definitions sit outside every namespace and are reachable across them.
• Shared services and missing quotas create cross-tenant effects. A shared service that serves all tenants, or an unquota'd tenant, lets one tenant observe or starve another.

Worked example (a confirm and a kill)

Confirm. Each tenant has a namespace, but a convenience cluster role grants tenants read on a cluster-scoped resource, and there is no network policy between namespaces. Acting as one tenant, a request lists a cluster-scoped object revealing another tenant's configuration, and a pod reaches another tenant's internal service directly. Confirmed namespace boundary failure across RBAC and network, high, remediation = remove cluster-scoped and cross-namespace grants from tenant roles, apply a default-deny network policy between tenant namespaces, and add resource quotas per tenant.

Kill. Every tenant identity is bound only within its own namespace with no cluster-scoped or cross-namespace grant, a default-deny network policy separates tenant namespaces, resource quotas bound each tenant, and shared services do not expose one tenant's data to another. A tenant cannot read another's resources, reach its pods, or exhaust shared capacity. Killed, kill_reason = "tenant RBAC namespace-scoped with no cluster-scoped grants, default-deny network policy between tenants, quotas enforced, and shared services isolated; the namespace confines the tenant."

Rationalizations to reject

• "Each tenant has its own namespace." → A namespace scopes names, not security; test RBAC reach, network reach, and shared resources before assuming it isolates.
• "RBAC is set per namespace." → Check for cluster-scoped roles and cross-namespace bindings; one cluster- scoped grant reaches every namespace.
• "Pods are separated by namespace." → Without a default-deny network policy, namespaces do not separate traffic; confirm segmentation between tenants.
• "They share the cluster, that is expected." → Sharing nodes and cluster-scoped resources is exactly where a namespace fails to isolate; audit the shared layer, not just the namespaces.
• "One tenant cannot affect another." → Confirm quotas exist; without them one tenant can exhaust shared capacity and deny service to the rest.

Executing this in practice

You need each tenant's RBAC bindings and their scope, the network policy between tenant namespaces, the cluster-scoped resources and nodes tenants share, the shared cluster services, and the resource quotas. For each isolation the boundary is assumed to provide, test whether one tenant can breach it. Reading the RBAC, policies, and quotas shows the intended boundary; acting as one tenant to reach another shows whether it holds.

Related

• auditing-multi-tenant-isolation - the general multi-tenant discipline; this skill applies it specifically to the namespace-as-boundary assumption in Kubernetes.
• auditing-network-policy-segmentation-gaps - the network half of the boundary; a namespace without inter- tenant network policy is not isolated.
• hunting-container-escape-surface - the node co-tenancy risk; a shared node plus an escape reaches another tenant's pods regardless of namespace.
• auditing-kubernetes-workload-and-rbac-hardening - the RBAC-scoping discipline this boundary depends on; cluster-scoped grants are where it breaks.
• FINDING-SCHEMA.md - source = the tenant confined to a namespace, sink = the cross-tenant resource or namespace it reaches, evidence = the isolation the namespace did not enforce.