generated from coulomb/repo-seed
82 lines
2.5 KiB
Markdown
82 lines
2.5 KiB
Markdown
# Pattern: Tenant Isolation
|
|
|
|
Status: draft
|
|
Readiness target: RL3 production
|
|
Primary owners: NetKingdom, Railiance platform, product repos
|
|
|
|
## Problem
|
|
|
|
Multi-tenant systems fail dangerously when tenant identity, runtime,
|
|
data, control-plane authority, or background jobs can cross boundaries
|
|
implicitly.
|
|
|
|
## Context
|
|
|
|
Use this pattern for SaaS products, shared clusters, shared databases,
|
|
object storage, platform services, admin tools, and asynchronous jobs.
|
|
|
|
## Forces
|
|
|
|
- Shared infrastructure improves efficiency.
|
|
- Tenants need strong data and authorization boundaries.
|
|
- Isolation may be implemented at namespace, cluster, cell, database,
|
|
key, policy, or API layers.
|
|
- Product teams need a clear contract for carrying tenant context.
|
|
|
|
## Solution
|
|
|
|
Make tenant context an explicit security boundary across identity,
|
|
authorization, runtime, data, audit, and operations. Choose isolation
|
|
strength per risk: namespace, cluster, cell, data partition, or isolated
|
|
data plane.
|
|
|
|
## Implementation Sketch
|
|
|
|
1. Define tenant id format and trust source.
|
|
2. Require tenant context in request and job envelopes.
|
|
3. Enforce tenant scope in flex-auth decisions.
|
|
4. Partition data and object storage by tenant.
|
|
5. Apply runtime and network boundaries for tenant workloads.
|
|
6. Record tenant id in audit and detection events.
|
|
|
|
## Failure Modes
|
|
|
|
| Failure | Mitigation |
|
|
| --- | --- |
|
|
| Tenant id accepted from untrusted input | derive from trusted identity/session claims |
|
|
| Background jobs lose tenant context | require job envelope tenant binding |
|
|
| Shared database queries miss tenant filter | add query guards and tests |
|
|
| Control plane can mutate tenant resources globally | add guardrails and review flows |
|
|
|
|
## Related Capabilities
|
|
|
|
- Tenant isolation.
|
|
- Authorization and access control.
|
|
- Data protection and privacy.
|
|
- Observability, detection, and audit.
|
|
|
|
## Maturity
|
|
|
|
Draft. The capability is central and well described; individual products
|
|
need concrete verification patterns.
|
|
|
|
## Verification
|
|
|
|
- Cross-tenant access tests fail for APIs, jobs, storage, and admin
|
|
paths.
|
|
- Tenant id is present in identity, authorization, and audit records.
|
|
- Data access includes tenant partition enforcement.
|
|
- Control-plane operations are tenant scoped unless explicitly platform
|
|
scoped.
|
|
|
|
## Research Basis
|
|
|
|
Seeded by tenant identity boundary, namespace-per-tenant,
|
|
cluster-per-tenant, cell-based architecture, isolated data plane,
|
|
tenant context propagation, and tenant data partitioning.
|
|
|
|
## References
|
|
|
|
- Initial exploration: Tenant isolation capability group.
|
|
- Initial exploration: Tenant isolation patterns.
|