[vcarl]

Defense-in-depth hardening for reactibot-deployment.

Changes

• Pod securityContext: run as uid/gid 1000 (node), runAsNonRoot, seccomp RuntimeDefault.
• Container: allowPrivilegeEscalation: false, drop ALL capabilities, readOnlyRootFilesystem: true, with an emptyDir at /tmp (HOME=/tmp for npm logs and the node compile cache).
• automountServiceAccountToken: false (the app doesn't use the k8s API).
• Declares containerPort: 3000. Fastify already listened there; the api.reactiflux.com 401 is the app's own api-key check.
• Resources: requests 64Mi / 10m (the node is near capacity) and limits 256Mi / 250m.
• New cluster/networkpolicy.yaml:
  • Ingress is allowed only from ingress-nginx on 3000.
  • Egress is allowed only to kube-dns on 53, and to the public internet on 443. The 443 rule excludes 10.0.0.0/8 and 169.254.0.0/16.

Verification

• kubectl kustomize . builds, a server-side dry-run succeeds, and kubectl diff -k . shows only the intended changes.
• Hubble flows and the code show only DNS and HTTPS 443 egress.
• The same settings are running on mod-bot's UAT without issues (Harden pod security: non-root, read-only rootfs, limits, NetworkPolicy Euno-HQ/discord#431). reactibot has no staging environment.

Rollout

⚠️ Merging deploys to prod (CI runs kubectl apply -k .). It is a rolling update, so if the new pod fails to start, the old one keeps serving.

• If it crash-loops on a read-only path, the fallback is to switch CMD to node dist/index.js.
• After merging, check that api.reactiflux.com still returns 401 rather than 502.

🤖 Generated with Claude Code