System distinction
A namespace scopes names for namespaced resources and provides a target for quota, authorization, admission, and network policy. A tenant is an accountability and isolation boundary. One tenant can use several namespaces, and a namespace alone is not hard isolation.
Control layers
Combine namespace ownership, RBAC, admission, quotas, NetworkPolicy, ServiceAccount and workload identity, secret access, node isolation, runtime policy, storage, logging, and control-plane administration. Protect cluster-scoped resources separately.
Cross-boundary access
Review cross-namespace references, service discovery, Gateway API attachment, shared controllers, operators, webhooks, volumes, nodes, certificate authorities, and observability. Record which controller identity can act across tenants.
Failure and residual risk
Broad cluster roles bypass namespace intent. Shared nodes expose kernel and runtime failure domains. Controllers can read secrets or create workloads across namespaces. Network and name isolation can differ. A namespace label is not workload attestation.
Pomerium boundary
Pomerium can protect named routes to tenant services. It does not enforce Kubernetes namespace isolation, RBAC, admission, node security, or storage boundaries. Operators must map route identity to the correct tenant and block cross-tenant direct paths.
Evaluation checklist
- Which accountable tenant owns each namespace and resource?
- Which cluster-scoped identities and controllers cross the boundary?
- Do RBAC, admission, network, secret, storage, node, and quota controls align?
- Can one tenant reference, discover, or reach another tenant's service?
- Does the application still enforce tenant-bound object access?
