This repository has been archived on 2026-07-08. You can view files and clone it. You cannot open issues or pull requests or push a commit.
Files
infospace-bench/infospaces/patterns-of-it-securita-architecture/artifacts/entities/pattern-tenant-isolation.md

2.5 KiB

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