Security Hardening Guide — Stella Ops

Audience — site-reliability and platform teams deploying Stella Ops in production or restricted networks.

See also: Security Hardening overview in the docs index, the Security Policy, and the Coordinated Vulnerability Disclosure policy.

Contents

1. Threat model (summary)
2. Host-OS baseline
3. Container & runtime hardening
4. Network-plane guidance
5. Secrets & key management
6. Image, SBOM & plug-in supply-chain controls
7. Logging, monitoring & audit
8. Update & patch strategy
9. Incident-response workflow
10. Pen-testing & continuous assurance
11. Vulnerability disclosure & contact
12. Change log

1 · Threat model (summary)

2 · Host-OS baseline checklist

3 · Container & runtime hardening

3.1 Docker Compose reference (compose-core.yml)

services:
  backend:
    image: registry.stella-ops.org/stella-ops/stella-ops:<PINNED_TAG_OR_DIGEST>
    user: "101:101"              # non-root
    read_only: true
    security_opt:
      - "no-new-privileges:true"
      - "seccomp:./seccomp-backend.json"
    cap_drop: [ALL]
    tmpfs:
      - /tmp:size=64m,exec,nosymlink
    environment:
      - ASPNETCORE_URLS=https://+:8080
      - TLSPROVIDER=OpenSslGost
    depends_on: [valkey]
    networks: [core-net]
    healthcheck:
      test: ["CMD", "wget", "-qO-", "https://localhost:8080/health"]
      interval: 30s
      timeout: 5s
      retries: 5

  valkey:
    image: valkey/valkey:8.0-alpine
    command: ["valkey-server", "--requirepass", "${VALKEY_PASS}", "--rename-command", "FLUSHALL", ""]
    user: "valkey"
    read_only: true
    cap_drop: [ALL]
    tmpfs:
      - /data
    networks: [core-net]

networks:
  core-net:
    driver: bridge

No dedicated “Valkey” or “PostgreSQL” sub-nets are declared; the single bridge network suffices for the default stack.

3.2 Kubernetes deployment highlights

• Use a separate NetworkPolicy that only allows egress from the backend to Valkey (Redis-compatible) on :6379.
• Set securityContext: runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation: false, and drop all capabilities.
• Add a PodDisruptionBudget of minAvailable: 1.
• Optionally enforce a CosignVerified=true label via an admission controller (for example, Kyverno or Connaisseur).

4 · Network-plane guidance

5 · Secrets & key management

Never bake secrets into images; always inject at runtime.

Operational tip: schedule a cron reminding ops 5 days before client.jwt expiry. The backend also emits a Prometheus metric stella_quota_token_days_remaining.

6 · Image, SBOM & plug-in supply-chain controls

• Images — pull by digest, not by latest, and verify the signature:

  cosign verify ghcr.io/stellaops/backend@sha256:<DIGEST> \
    --key https://stella-ops.org/keys/cosign.pub
  

• SBOM — each release ships an SPDX file; store it alongside the images for audit.

• Third-party plug-ins — place them in /plugins/; the backend will:

  • Validate the Cosign signature.
  • Check the [StellaPluginVersion("major.minor")] attribute.
  • Refuse to start when an unsigned plug-in is present (Security.DisablePluginUnsigned=false, the default).

See the Plugin SDK Guide for signing and version-compatibility details.

7 · Logging, monitoring & audit

7.1 Concelier authorization audits

• Enable the Authority integration for Concelier (authority.enabled=true). Keep authority.allowAnonymousFallback set to true only during migration, and disable it as soon as migration completes so the /jobs* surface always demands a bearer token.
• Store the Authority client secret using Docker/Kubernetes secrets and point authority.clientSecretFile at the mounted path; the value is read at startup and never logged.
• Watch the Concelier.Authorization.Audit logger. Each entry contains the HTTP status, subject, client ID, scopes, remote IP, and a boolean bypass flag showing whether a network bypass CIDR allowed the request. Configure your SIEM to alert when unauthenticated requests (status=401) appear with bypass=true, or when unexpected scopes invoke job triggers. Detailed monitoring and response guidance lives in docs/modules/concelier/operations/authority-audit-runbook.md.

8 · Update & patch strategy

9 · Incident-response workflow

• Detect — PagerDuty alert from Prometheus or SIEM.
• Contain — stop the affected backend container; isolate the Valkey RDB snapshot.
• Eradicate — pull verified images, redeploy, rotate secrets.
• Recover — restore the RDB and replay SBOMs if history was lost.
• Review — post-mortem within 72 h; create follow-up issues.
• Escalate — route P1 incidents to security@stella-ops.org (24 × 7).

10 · Pen-testing & continuous assurance

11 · Vulnerability disclosure & contact

• Preferred channel: security@stella-ops.org (GPG key on the website).
• Full process: see the Coordinated Vulnerability Disclosure policy and the Security Policy.
• Coordinated-disclosure reward: public credit and swag (no monetary bounty at this time).

12 · Change log