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

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.