# 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.