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