Security Boundaries (Platform-Level)

This document describes the baseline security boundaries every StellaOps module is expected to uphold: authentication and authorization, network segmentation, CORS, data protection, and auditability. It is the platform-level contract — individual module dossiers may impose stricter requirements, but never weaker ones.

Audience: service authors, platform operators, and reviewers verifying that a service meets the minimum security bar before it is exposed.

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:

• Scopes and roles
• Authority architecture
• Signer architecture
• Attestor architecture

The canonical scope catalog is StellaOpsScopes.cs (src/Authority/StellaOps.Authority/StellaOps.Auth.Abstractions/); ASP.NET policy names may differ from scope claim values, so verify both against source.

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

The deployment bundles under devops/ (Docker Compose profiles and Helm charts) are the authoritative source for concrete network layouts.

Cross-Origin Resource Sharing (CORS)

All Stella Ops web services use a shared CORS extension provided by StellaOps.AspNet.Extensions (StellaOpsCorsExtensions), with settings resolved by StellaOps.Settings (StellaOpsCorsSettings).

Development mode

When the host environment is Development, CORS is automatically enabled with specific origins, AllowAnyHeader, AllowAnyMethod, and AllowCredentials.

Default dev origins (used when no explicit origin is configured):

• https://stella-ops.local
• https://stella-ops.local:10000
• https://localhost:10000

Override the defaults by setting STELLAOPS_WEBSERVICES_CORS_ORIGIN.

Non-development (staging / production)

CORS is disabled by default. To enable, set the following environment variables (or their YAML/appsettings equivalents):

Legacy fallback

The following legacy env vars and config keys are still supported as fallbacks (resolved after the primary keys above):

Resolution order

Settings are resolved with a priority cascade (first non-empty value wins):

1. Primary env var (STELLAOPS_WEBSERVICES_CORS / STELLAOPS_WEBSERVICES_CORS_ORIGIN)
2. Primary config key (StellaOps:WebServices:Cors:Enabled / StellaOps:WebServices:Cors:Origin)
3. Legacy env var (STELLAOPS_CORS_ENABLED / STELLAOPS_CORS_ALLOWED_ORIGIN)
4. Legacy config key (StellaOps:Cors:Enabled / StellaOps:Cors:AllowedOrigin)
5. Default: true in Development, false otherwise

When CORS is enabled, the policy always uses:

• WithOrigins(...) (only the configured/default origins — never AllowAnyOrigin)
• AllowAnyHeader
• AllowAnyMethod
• AllowCredentials

Integration in services

Every web service’s Program.cs includes:

using StellaOps.Auth.ServerIntegration;

// In service registration (before builder.Build())
builder.Services.AddStellaOpsCors(builder.Environment, builder.Configuration);

// In middleware pipeline (before UseAuthentication)
app.UseStellaOpsCors();

Source

The implementation lives in:

• src/__Libraries/StellaOps.Settings/StellaOpsCorsSettings.cs (POCO + resolution logic)
• src/__Libraries/StellaOps.AspNet.Extensions/StellaOpsCorsExtensions.cs (ASP.NET DI + middleware)
• Transitive reference via StellaOps.Auth.ServerIntegration (so existing service references continue to work)

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.

Related documentation

• Data Isolation — per-tenant isolation model
• Platform Topology — network and service layout
• Port Registry — service ports and exposure
• Scopes and roles — authorization catalog