git.stella-ops.org/docs/technical/architecture/security-boundaries.md

Security boundaries (platform-level)

This document describes the baseline security boundaries expected across StellaOps modules. Module dossiers may impose stricter requirements.

Authentication and authorization

All externally reachable services are expected to enforce:

1. Token validation (short-lived, tenant-scoped access tokens).
2. Sender constraints where configured (DPoP / mTLS).
3. Scope-based authorization (least privilege).
4. Tenant isolation: requests and data access are filtered by tenant context.

Hard gates (typical examples)

Exact gates are module-specific, but common patterns include:

• Authority: nonce-based sender constraints (DPoP), strict token lifetimes, tenant-scoped issuance, and rate limiting.
• Signing/attestation services: narrow scopes, service identity requirements (often mTLS), and verification of the artifact being signed/attested (for example digest checks) before producing evidence.

Authoritative references:

• docs/security/scopes-and-roles.md
• docs/modules/authority/architecture.md
• docs/modules/signer/architecture.md
• docs/modules/attestor/architecture.md

Network segmentation (typical deployment)

• Front door / ingress: TLS termination, rate limiting, and WAF controls.
• Gateway layer: authenticated routing and tenant resolution; exposes only required service surfaces.
• Private service network: internal service-to-service traffic (least privilege, explicit allowlists).
• Stateful infrastructure: PostgreSQL, Valkey, object storage, message brokers (not directly internet-exposed).

Deployment bundles under deploy/ are the authoritative source of concrete network layouts.

Data protection

• TLS for in-transit protection (including internal traffic where required by the profile).
• Secrets must not be embedded in documentation examples; use a secrets provider (file, Docker secrets, Kubernetes secrets, vault).
• Evidence artifacts should be written to content-addressed or immutable stores where replay/audit requires it.

Auditability

The platform is designed for audits:

• Deterministic outputs for the same inputs.
• Evidence artifacts (SBOM slices, advisories/VEX observations, explain traces) linkable to digests.
• Structured logs and correlation IDs for tracing request paths across services.