Skip to main content

Security

This page expands Section 6 from Architecture Overview.

Security reading strategy

Review this page layer by layer: boundary, network, token, data-plane, then runtime hardening.

Security Model (Practical)​

Isolation and exposure boundaries​

  • Challenge pods are not exposed directly to users.
  • Access boundary is Challenge Gateway only.
  • Per-challenge namespace segmentation limits blast radius.

Network policy enforcement​

Application namespace policies restrict ingress/egress by service role:

  • Contestant Service can reach DB + Redis + Deployment Center.
  • deployment services can reach DB + Redis + Argo + RabbitMQ.
  • Challenge Gateway egress is restricted to challenge namespaces, Redis, DNS.

Challenge namespace policies enforce:

  • default deny ingress,
  • allow ingress only from Challenge Gateway,
  • strict egress with RFC1918 and metadata block exceptions.

Runtime token security​

  • Challenge access token payload contains route + expiry.
  • Token is HMAC-SHA256 signed with PRIVATE_KEY.
  • HTTP flow rotates token from URL to HttpOnly cookie.
  • TCP flow performs explicit token authentication before proxying.
  • Sessions are closed when token expiry is reached.
Token scope discipline

Challenge tokens should remain short-lived and scoped to route and team context. Avoid adding broad permissions into runtime access tokens.

Data-plane access controls​

Redis ACL​

  • Per-service users with command and key-prefix scoping.
  • Challenge Gateway user constrained to fctf:gateway:* keyspace.
  • Deployment services constrained to deploy_challenge_* and active_deploys_team_* patterns.

MariaDB least privilege​

  • Separate DB accounts per service (contestant_be, deployment_center, deployment_consumer, deployment_listener).
  • Grants are table-scoped, not broad schema ownership.

RabbitMQ separation​

  • Distinct vhost and queue/exchange topology for deploy flow.
  • Producer/consumer roles are logically separated.

Service account and RBAC model​

  • Deployment Center and Deployment Consumer have Argo namespace roles for workflow operations.
  • Deployment Listener has broad cluster watch/delete permissions required for reconciliation.
  • Argo workflow service accounts are token-based and template-specific.

Known security trade-offs​

  • start-chal-v2 currently uses cluster-admin binding for reliability in complex namespace provisioning; this is operationally simple but broad in privilege.
  • gVisor sandboxing (runtimeClassName: gvisor) reduces kernel attack surface for untrusted challenge code, but may require per-challenge compatibility/performance tuning.
  • Some internal TLS verification is relaxed for internal services (for example, Argo/self-signed scenarios) to reduce bootstrap friction; production hardening should revisit this trust model.
  • Deployment Center callback endpoint authentication should be reviewed to ensure strict verification in all environments.
Hardening priority

Prioritize tightening broad RBAC and callback authentication before adding new runtime features.