Files
git.stella-ops.org/docs/security/tenancy-overview.md
StellaOps Bot 7503c19b8f Add determinism tests for verdict artifact generation and update SHA256 sums script
- Implemented comprehensive tests for verdict artifact generation to ensure deterministic outputs across various scenarios, including identical inputs, parallel execution, and change ordering.
- Created helper methods for generating sample verdict inputs and computing canonical hashes.
- Added tests to validate the stability of canonical hashes, proof spine ordering, and summary statistics.
- Introduced a new PowerShell script to update SHA256 sums for files, ensuring accurate hash generation and file integrity checks.
2025-12-24 02:17:34 +02:00

36 lines
2.1 KiB
Markdown

# Tenancy Overview
StellaOps is designed for strict multi-tenancy. Tenancy is an explicit input to requests, storage, and exported evidence so decisions remain auditable and replayable (including in air-gapped deployments).
## Tenant Identity
- A **tenant** is the primary isolation boundary for data, policies, issuers/trust settings, and workflow objects (exceptions, approvals, exports).
- Requests are tenant-scoped via `X-StellaOps-Tenant: <tenantId>` and/or tenant claims in tokens (depending on deployment).
Optional sub-scoping (environment/project/workspace) is supported via ABAC claims and module-specific selectors, but does not replace the tenant boundary.
## Isolation Guarantees
StellaOps aims for defense-in-depth isolation:
- **Database isolation:** each service owns its schema; tenant scoping is enforced on every query, typically via `tenant_id` columns and Row-Level Security where appropriate.
- **Cache isolation:** cache keys and stream partitions are tenant-aware (and may use per-tenant databases in Redis/Valkey-compatible stores when configured).
- **Object storage isolation:** stored artifacts and evidence bundles are content-addressed and namespaced so tenant boundaries are preserved even when sharing infrastructure.
- **Audit boundaries:** audit trails are tenant-scoped and exported with tenant identifiers so offline reviewers can verify context.
## Enforcement Stack
- **Authority** issues tokens containing scopes and optional ABAC claims.
- **Gateway** (when deployed) routes and enforces tenant + scope checks consistently across modules.
- **Services** validate tenant context and enforce tenant constraints at the storage layer.
## Offline / Air-Gap Considerations
- Offline Kit snapshots and exported evidence bundles include tenant identifiers and deterministic manifests so verification does not rely on online services.
- Cross-tenant exports are not supported by default; when an operator needs cross-tenant reporting, it should be implemented as an explicit, audited workflow.
## References
- Scope taxonomy: `docs/security/scopes-and-roles.md`
- Gateway tenant auth contract: `docs/api/gateway/tenant-auth.md`