infospace-bench/infospaces/patterns-of-it-securita-architecture/artifacts/entities/pattern-namespace-per-tenant.md

Pattern: Namespace-per-Tenant

Status: seed Readiness target: RL2 private beta Primary owners: Railiance platform, product repos Genesis family: Tenant isolation

Problem

Shared Kubernetes clusters need tenant boundaries without the cost and operational overhead of one cluster per tenant.

Context

Use this pattern for medium-strength tenant isolation where workloads can share a cluster but need separate Kubernetes namespaces, resource quotas, network policies, and access controls.

Forces

• Shared clusters reduce platform cost.
• Namespaces are not a hard security boundary by themselves.
• Tenant workloads need quotas, labels, policies, and ownership.
• Platform controllers can accidentally gain cross-tenant reach.

Solution

Assign each tenant one or more namespaces with mandatory labels, resource quotas, network default deny, RBAC boundaries, admission policies, and tenant-aware audit events.

Verification

• Tenant service accounts cannot access other tenant namespaces.
• Network policies block cross-namespace traffic unless allowed.
• Quotas and pod security policies apply to every tenant namespace.
• Audit records include namespace and tenant id.

Related Patterns

• Tenant Isolation.
• Network Default Deny.
• Pod Security Baseline/Restricted.
• Tenant Context Propagation.