Privileged Kubernetes Workload
- Category
- Tool Misuse
- Confidence
- 92% confidence
- Finding
Although the static rule labels this a Kubernetes workload, the document describes a privileged Docker execution service. Running a service that processes potentially untrusted code with privileged container access increases the consequences of an nsjail or service compromise, potentially including host compromise; an internal-only network does not remove that local privilege risk.
- Content
md ARED=1`) or Tailscale (`TAILSCALE=1`) — both keep no ports open on the host — or put a real authenticating gateway/reverse-proxy in front of it. - Every request needs `Authorization: Bearer $AIGATE_TOKEN` (or a per-service override token) — there is no unauthenticated path once a service is enabled. Don't hardcode the token in scripts committed to a repo; source it from `.env`/environment. - Internal services (Postgres, Redis, LiteLLM, and most optional services) bind to no host ports at all — only nginx is exposed. Don't add host port mappings for internal services unless you specifically need direct access and understand you're widening the blast radius. - `piston` runs `privileged: true` (required for nsjail's own isolation, not a bypass of it) and lives on an internal-only network with no outbound internet — don't change that without understanding why. - Guard `.env` and any mailbox/Telethon config files — they hold plaintext secrets and are gitignored for a reason. ## When to use
