Security Principles

STING CE implements defense-in-depth with a zero-trust architecture:

1. Zero Trust — never trust, always verify. Every request is authenticated.
2. Least Privilege — each service and database user has minimal permissions.
3. Defense in Depth — multiple independent security layers.
4. Security by Design — security is built in, not bolted on.
5. Data Sovereignty — all data stays on your infrastructure. No external telemetry.

Authentication

Ory Kratos

Authentication is handled by Ory Kratos (container sting-ce-kratos, ports 4433/4434), a headless identity management system. STING CE supports:

Auth Middleware

The Flask API validates every request through KratosAuthMiddleware. Route-level decorators enforce access requirements:

@require_auth          # Authenticated user required
@require_aal2          # MFA (AAL2) verified session required
@require_admin         # Admin role required

The auth flow:

Request → KratosAuthMiddleware
       → Validates session cookie with Kratos API
       → Extracts user identity and AAL level
       → Injects user context into request
       → Route handler executes (or 401/403)

Session Management

Sessions are managed by Kratos with tokens stored in secure, HTTP-only cookies. Session lifetime and idle timeout are configurable via Kratos configuration. Redis is used for session caching to reduce Kratos API calls.

Authorization

STING CE uses role-based access control (RBAC):

Ownership checks ensure users can only access their own resources unless explicitly shared or the user has an elevated role.

Encryption

In Transit

• External traffic — TLS everywhere. Development uses mkcert self-signed certificates. Production deployments use Let’s Encrypt via sudo msting setup-ssl.
• Internal traffic — services communicate over the private sting_local Docker network. Internal traffic is not encrypted by default (network-level isolation provides the boundary).

At Rest

• Database — PostgreSQL pgcrypto extension for field-level encryption of sensitive data.
• Vault — all secrets encrypted at rest using Vault’s storage backend encryption.
• Backups — optional AES-256 encryption via sudo msting backup --encrypt.

Key Management

All encryption keys and API credentials are stored in HashiCorp Vault. No secrets are hardcoded in source code, environment files, or Docker images. Keys can be managed with:

sudo msting vault-secret list                 # List stored API key providers
sudo msting vault-secret openai <key>         # Store an API key
sudo msting encryption-keys status            # Check encryption key health

Network Security

Docker Network Isolation

All services run on a private Docker bridge network (sting_local). No service port is exposed to the public internet by default — the Nginx frontend is the sole ingress point.

Internet → Nginx (frontend :8443) → Internal services
                                      ├── app :5050
                                      ├── knowledge :8090
                                      ├── messaging :8889
                                      └── ...

Rate Limiting

Nginx applies rate limiting on public-facing endpoints:

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=auth:10m rate=5r/m;
limit_req_zone $binary_remote_addr zone=ai:10m rate=2r/s;

Authentication endpoints are heavily rate-limited to prevent brute-force attacks.

Container Security

All application containers follow a hardened pattern:

• Non-root execution — containers create an appuser (UID 1000) and run as that user.
• Minimal base images — python:3.11-slim for backend services, nginx:1.27-alpine for web servers.
• Health checks — every service defines a HEALTHCHECK directive (30s interval, 10s timeout, 40s start period, 3 retries).
• No privileged mode — no container runs with --privileged.
• Read-only where possible — configuration files are mounted read-only.

PII Detection

STING CE includes PII (Personally Identifiable Information) detection middleware in the Flask application. This middleware automatically scans:

• File uploads to Honey Jars
• Message content in the messaging service
• User-submitted text in conversations

Detected PII is flagged for review. This helps organizations comply with data handling policies without manual content inspection.

CORS Configuration

Cross-Origin Resource Sharing is configured per-service via environment variables. Each FastAPI microservice reads its allowed origins from its .env file, ensuring tight control over which domains can make cross-origin requests.

Secrets Management

STING CE uses HashiCorp Vault as the single source of truth for all secrets:

• Database credentials
• API keys (LLM providers, external services)
• Encryption keys
• Inter-service authentication tokens

Vault is initialized and unsealed during installation. If Vault becomes sealed (e.g., after a restart), use sudo msting unseal to restore access.

Security Reporting

Vulnerability reports should be sent to security@alphabytez.dev. Do not open public issues for security vulnerabilities. See SECURITY.md for the full disclosure policy.

Threat Model

Assets to Protect

Attack Vectors and Mitigations