Skip to content

How to harden a HAProxy container (and is haproxy:3.1-alpine safe at your edge?)

HAProxy sits in the request path: it terminates TLS, load-balances every inbound connection, and is the first thing an attacker reaches. A stock docker run haproxy:3.1-alpine is better than most edge images out of the box, but it is not yet the boundary that role deserves. Graded on IronClaw's seven-dimension containment scale, the default configuration scores 63 of 100, grade C (partial). Higher is safer. A few runtime flags take the same image to 89 of 100, grade B, one point off an A, and the one dimension it cannot reach is the one a load balancer needs by definition: it exists to accept and forward traffic. Here are the exact gaps and fixes from the scan data.

Graded from a read-only inspect of a running container started from haproxy:3.1-alpine with plain docker run defaults, its entrypoint overridden with sleep purely to keep it alive. The scan itself executes nothing inside the container. It is the same data behind its isolation scorecard. How scoring works →

Where the default configuration leaks

ironctl scan grades seven independent containment boundaries. On a default docker run haproxy:3.1-alpine, two fail and one warns. It already runs as a non-root user, which is why it starts a full grade above most edge images:

Dimension Verdict Score What the scan found
Non-root user (uid != 0) ✅ PASS 15/15 runs as haproxy (uid != 0)
Dropped capabilities ❌ FAIL 4/20 default capability set retained (CAP_NET_RAW, CAP_MKNOD, and more)
Seccomp profile ✅ PASS 15/15 seccomp profile active
Network isolation / egress ⚠️ WARN 4/15 network=bridge: outbound egress is possible
Read-only root filesystem ❌ FAIL 0/10 root filesystem is writable
No docker.sock exposure ✅ PASS 15/15 no control socket mounted
No shared host namespaces ✅ PASS 10/10 no host PID/IPC/network sharing

HAProxy already gets the hardest dimension right by dropping to a non-root uid. The two that remain are the full capability set and the writable rootfs. HAProxy parses attacker-controlled bytes on every request; a routing or TLS CVE that lands code execution keeps CAP_NET_RAW to craft raw packets and a writable rootfs to persist, unless you take them away. Neither is needed to forward traffic.

Harden it: the exact --fix remediation

ironctl scan my-haproxy --fix prints one remediation per failed dimension, then one hardened run. For haproxy:3.1-alpine:

  • --cap-drop=ALL (Dropped capabilities, +16): drop every Linux capability, then add back only CAP_NET_BIND_SERVICE if you must bind 80/443 directly. The scan below reflects dropping the full set with ports mapped high; adding one cap back costs 4 points (a WARN, still grade B territory).
  • --read-only --tmpfs /tmp (Read-only rootfs, +10): make the root filesystem read-only. HAProxy runs happily read-only; mount a writable volume only if you use its runtime state or maps.
  • --user 99:99 (Non-root user, already +15): the image already drops to the haproxy uid, so this dimension is closed by default. Keep it pinned if you override the entrypoint.
  • Scoped network (Network isolation): --network=none scores the full 15 but is wrong for a load balancer, it exists to forward traffic. Any named or bridge network scores 4 of 15 (a WARN, not a fail): a connection path exists. Contain it anyway: put HAProxy on a user-defined network scoped to just the backends it fronts, with no default route out, so a compromised proxy cannot call arbitrary internet addresses.

Before and after

# Before: 63/100, grade C
docker run -d --name haproxy haproxy:3.1-alpine

# After: 89/100, grade B (scoped private network for its backends)
docker run -d --name haproxy-hardened \
  --user 99:99 \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  --read-only --tmpfs /tmp \
  -p 8080:8080 -p 8443:8443 \
  --network=edge-internal \
  haproxy:3.1-alpine

Rescan: ironctl scan haproxy-hardened reports 89/100 grade B. A 26-point swing with no custom image build, just the right flags. The only dimension still short of full marks is the network (4 of 15), because a load balancer exists to accept connections; network=none would score the last points but leave nothing able to reach or be reached. That is the honest ceiling for a proxy, and a solid grade B.

Verify it on your own HAProxy

# install (Homebrew)
brew install ironsecco/ironclaw/ironclaw

# grade your running container, then print the fixes
ironctl scan my-haproxy
ironctl scan my-haproxy --fix

ironctl scan also reads a docker-compose.yml service or a Kubernetes manifest, so you can grade the HAProxy in your stack, not just a bare docker run.

Keep going