generated from coulomb/repo-seed
45 lines
1.3 KiB
Markdown
45 lines
1.3 KiB
Markdown
# 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.
|