The goal is confinement, not invulnerability. Docker introduces a quantifiable reduction in blast radius — from full host compromise to a contained process sandbox. For an algorithmic book whose API keys function as direct, irrevocable transfer authority on a centralized venue, that arithmetic is the difference between a recoverable incident and total loss of operational capital.
How Namespaces and Cgroups Redefine the Trust Boundary
Bare-metal bot deployment collapses every process into one trust zone. The trading application, the SSH daemon, the cron scheduler, and the exchange client all share the same kernel view: they enumerate each other, signal each other, and read each other's files within the boundaries of filesystem permissions. A path traversal in the bot's strategy code, a vulnerable dependency, or a leaked SSH credential grants the attacker unrestricted access to the entire host.
Docker intervenes by inserting the Linux kernel's namespace primitives between the bot process and the host.
- PID namespace. The container's processes start at PID 1 inside their own hierarchy. They see no host processes, cannot signal
init, and cannot enumerate peer workloads running on the VPS. - Network namespace. The bot receives a virtual interface on a private bridge. Host ports and inter-container traffic remain invisible unless explicitly routed.
- Mount namespace. The container's root filesystem is an overlay; the host's
/etc,/root,/home, and/vardo not exist from the bot's perspective. A path traversal never reaches the host's filesystem layout. - User namespace. UID 0 inside the container maps to a high-numbered, unprivileged UID on the host. Container root is not host root.
Cgroups layer a second primitive: resource accounting and limits. The container's CPU share, memory ceiling, block I/O weight, and PID count become hard caps. A runaway strategy loop, an out-of-memory exception, or a fork bomb remains bounded — the host's session manager, SSH stack, and concurrent workloads stay operable.
A correctly configured container is not a security boundary. It is a quantitative reduction in blast radius. Treat it as one layer of a defense-in-depth stack, not the terminal defense.
Enforcing Non-Root Execution and Capping Resources
Running the bot as UID 0 inside a container is equivalent to running it as root on the host in any default configuration that does not enable user namespace remapping. The first non-negotiable is dropping root.
| Control | Docker flag / mechanism | Effect |
|---|---|---|
| Non-root UID | --user 10001:10001 (UID > 1000) | Container processes run as unprivileged user |
| Capability drop | --cap-drop=ALL | Removes all Linux capabilities; reintroduce only NET_BIND_SERVICE if binding a low port |
| Privilege escalation lock | --security-opt=no-new-privileges | Prevents setuid binaries from regaining privileges inside the container |
| Seccomp filter | --security-opt seccomp=custom-profile.json | Restricts available syscalls; blocks pivot to host kernel exploits |
| CPU ceiling | --cpus=1.5 | Cgroup caps compute share |
| Memory ceiling | --memory=512m --memory-swap=512m | Cgroup caps RAM; OOM-killer contained to container |
| PID ceiling | --pids-limit=100 | Cgroup caps fork count; fork bombs neutralized |
These flags are applied at docker run, not in the Dockerfile. Bake-time configuration cannot guarantee runtime policy; deployment-time configuration can.
Injecting API Credentials at Runtime, Not Build Time
API keys with Trade permission still permit placing orders; only Withdrawal and Transfer enable fund exfiltration. The exchange-side restriction of permissions is the single most consequential control — but container discipline determines whether the key is reachable from the container at all.
Hardcoded environment variables in a Dockerfile live forever in every image layer, distributed to every registry pull, and recoverable from any layer that ever contained them. The risk surface is permanent.
- Docker Secrets. Swarm-mode secret mounts bind to
/run/secrets/<name>inside the container; values never appear indocker inspectoutput and never touch image layers. - HashiCorp Vault, Bitnami Sealed Secrets, or
sops-encrypted env files. The decryption key lives on the host, not in the repository. The bot reads the credentials at process start. .envfile mount at runtime withchmod 600on the host. Inject via--env-file, not--env.
Combined with an IP allow-list on the exchange (the bot VPS's egress IP only), a stolen key becomes inert outside the source network — a partial, not total, loss.
Read-Only Filesystems and Ephemeral Tmpfs Mounts
A writeable container filesystem is a persistence vector for an attacker. Dropped binaries, modified strategy code, and crontab implants all require write access.
docker run --read-only removes the ability for any process inside the container to create, modify, or delete files on the container's root filesystem. Anything that legitimately requires write access — log buffers, scratch directories, SQLite databases — is mounted explicitly:
--tmpfs /tmp:size=100m,uid=10001— ephemeral, size-capped, owned by the bot user.- Named volumes for persistent state (databases, trade history) — backed up off-host, never mounted read-write beyond what the process requires.
- Logs shipped externally via a sidecar, a network log forwarder, or a
docker logsconsumer — kept out of the container's filesystem.
A container that cannot persist state cannot be backdoored into persistence either.
Segmenting the Network So the Bot Sees Only What It Must
Default bridge networking in Docker is permissive: every container on the default bridge can reach every other container, and outbound traffic to the internet is unrestricted. For a trading book with n strategies across m exchanges, that is the wrong baseline.
- User-defined bridge networks, one per logical trust group, assigned to specific containers with
docker network connect. Cross-container traffic does not exist by default. - No
--network host. Host networking collapses the container's network namespace into the host's; isolation is forfeited. - Egress filtering at the host firewall (
iptables,nftables, or a managed cloud security group). Allow outbound TCP to exchange API endpoints on port 443 only. Deny everything else. - No inbound ports published. Bots are outbound-only clients. Any
EXPOSEor-pdirective on the container is a misconfiguration unless the operator runs an authenticated local dashboard behind a reverse proxy.
Outbound-only. No inbound. No host network. No default bridge. Network policy is the most neglected layer of bot infrastructure because its failures do not surface until incident response.
Verifying Isolation: How to Check That the Sandbox Is Actually a Sandbox
Architectural claims about isolation are not isolation. The deployment must be testable. Operators run a fixed protocol at every container build and after every host configuration change.
1. docker inspect <container> — confirm User (non-root UID), ReadonlyRootfs: true, CapDrop: ["ALL"], SecurityOpt: ["no-new-privileges"], and that NetworkMode is not host.
2. docker exec -it <container> /bin/sh — attempt touch /testfile: should fail under --read-only. Attempt cat /host/etc/passwd: the path does not resolve. Confirm the absence of host paths from the mount namespace.
3. ps -ef from inside the container — only the bot's PID tree should be visible. A populated host process list indicates PID namespace leakage, a confirmed misconfiguration.
4. capsh --print from inside — the bounding and effective capability sets should be empty. Non-empty values indicate an over-broad capability grant.
5. Memory and CPU containment — run stress-ng --cpu 4 --vm 2 --vm-bytes 2G --timeout 30s. The host's responsiveness, SSH daemon, and other containers should remain unaffected; OOM-kill events should fire inside the container, not propagate to the host.
6. Egress filtering — curl -v https://169.254.169.254/ (the cloud metadata endpoint) should be refused or return 403; outbound to non-allowlisted hosts should be blocked at the host firewall layer.
7. Image-layer credential audit — docker history --no-trunc <image> should reveal no ENV KEY=... entries; trivy image or grype should report zero high-severity CVEs in the bot's runtime libraries.
A failure on any single point forces redeployment. The cost of a corrected docker run invocation is small. The cost of a leaked Withdrawal-enabled key on a production VPS is not.
Closing Verdict
Containerized isolation does not eliminate the probability of a bot vulnerability. It bounds the consequence. Namespaces fragment the trust surface; Cgroups cap the resource cost; non-root execution and capability drops remove host-level escalation paths; runtime credential injection prevents key persistence in image artifacts; read-only filesystems and bounded tmpfs deny attacker persistence; network segmentation denies lateral movement and limits exfiltration pathways.
For a quantitative operation, the calculation is straightforward. The expected loss of a fully compromised VPS hosting unrestricted API keys is the exchange account balance plus the operational cost of incident response. The expected loss of a properly containerized bot with Trade-only API permissions, non-root execution, network egress filtering, and read-only filesystem is, in the worst case, the value of the bot's strategy code and the cost of redeployment — not the exchange balance. The Sharpe ratio of that risk reduction is not aesthetic. It is operational.
Operators who track market context across daily outlets can read a piece like nevlanews.com for macro color. The containment math, however, is enforced in the daemon configuration — daemon.json, the docker run flags, the host firewall ruleset, and the exchange-side API permission matrix. None of those execute themselves.
