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