generated from coulomb/repo-seed
46 lines
1.3 KiB
Markdown
46 lines
1.3 KiB
Markdown
# Pattern: Cluster-per-Tenant
|
|
|
|
Status: seed
|
|
Readiness target: RL4 regulated production
|
|
Primary owners: Railiance platform
|
|
Genesis family: Tenant isolation
|
|
|
|
## Problem
|
|
|
|
Some tenants require stronger runtime and control-plane separation than
|
|
namespace isolation can provide.
|
|
|
|
## Context
|
|
|
|
Use this pattern for regulated customers, high-trust deployments,
|
|
dedicated environments, high-risk workloads, or tenants with contractual
|
|
isolation requirements.
|
|
|
|
## Forces
|
|
|
|
- Separate clusters increase isolation and blast-radius control.
|
|
- More clusters increase operational complexity and cost.
|
|
- Shared platform services still need consistent identity, policy,
|
|
secrets, and audit contracts.
|
|
- Tenant lifecycle and upgrades must remain manageable.
|
|
|
|
## Solution
|
|
|
|
Allocate a dedicated Kubernetes cluster or equivalent control boundary
|
|
per tenant while preserving shared NetKingdom identity, authorization,
|
|
secret, deployment, and audit contracts.
|
|
|
|
## Verification
|
|
|
|
- Tenant workloads cannot share Kubernetes control-plane authority.
|
|
- Cluster credentials, secrets, and audit sinks are tenant scoped.
|
|
- Shared platform integrations preserve tenant identity and ownership.
|
|
- Restore and upgrade procedures are tested per tenant cluster class.
|
|
|
|
## Related Patterns
|
|
|
|
- Tenant Isolation.
|
|
- Shared Control Plane, Isolated Data Plane.
|
|
- Central Audit Ledger.
|
|
- Secure Cluster Baseline.
|