generated from coulomb/repo-seed
46 lines
1.3 KiB
Markdown
46 lines
1.3 KiB
Markdown
# Pattern: Shared Control Plane, Isolated Data Plane
|
|
|
|
Status: seed
|
|
Readiness target: RL3 production
|
|
Primary owners: NetKingdom, Railiance platform
|
|
Genesis family: Tenant isolation
|
|
|
|
## Problem
|
|
|
|
Platforms often need centralized management while tenant workloads and
|
|
data require stronger separation than the control plane itself.
|
|
|
|
## Context
|
|
|
|
Use this pattern for SaaS management planes, tenant runtime clusters,
|
|
dedicated object storage, per-tenant databases, or cell-based data
|
|
planes.
|
|
|
|
## Forces
|
|
|
|
- Shared control planes reduce management overhead.
|
|
- Tenant data planes need stronger isolation and blast-radius control.
|
|
- Control-plane actions are high impact and must be tenant scoped.
|
|
- Audit must explain who affected which tenant data plane.
|
|
|
|
## Solution
|
|
|
|
Keep management APIs and policy orchestration in a shared control plane,
|
|
but isolate tenant runtime and data paths. Every control action carries
|
|
tenant, target plane, actor, policy, and audit context.
|
|
|
|
## Verification
|
|
|
|
- Tenant users cannot mutate global control-plane state unless
|
|
delegated.
|
|
- Data-plane credentials and network paths are tenant scoped.
|
|
- Control-plane actions produce tenant and target-plane audit events.
|
|
- A compromised tenant data plane cannot directly control another.
|
|
|
|
## Related Patterns
|
|
|
|
- Tenant Isolation.
|
|
- Cluster-per-Tenant.
|
|
- Cell-based Architecture.
|
|
- Tenant Data Partitioning.
|