Skip to content

How to harden a Redpanda container (and is redpanda:v24.2.11 safe for untrusted workloads?)

A streaming broker sits between every producer and consumer you run, which is exactly why its container should be one of the tightest. A stock docker run redpandadata/redpanda:v24.2.11 is not that. Graded on IronClaw's seven-dimension containment scale, the default configuration scores 63 of 100, grade C (partial). Higher is safer. A couple of 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 broker needs by definition (clients must connect to it). Here are the exact gaps and fixes from the scan data.

Graded from a read-only inspect of a running container started from redpandadata/redpanda:v24.2.11 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 redpandadata/redpanda:v24.2.11, three fail or warn:

Dimension Verdict Score What the scan found
Non-root user (uid != 0) ✅ PASS 15/15 runs as redpanda (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

Redpanda already runs as a non-root uid, which is why it clears the default 48/100 that root images sit at. The sharpest remaining edges are the retained capabilities and open egress: a Kafka-protocol or admin-API CVE that lands code execution lands it with CAP_NET_RAW and friends, on a process every service in your stack already trusts and connects to, and it can reach the network to exfiltrate every message on the log.

Harden it: the exact --fix remediation

ironctl scan my-redpanda --fix prints one remediation per failed dimension, then one hardened run. For redpandadata/redpanda:v24.2.11:

  • --cap-drop=ALL (Dropped capabilities, +16): drop every Linux capability; add back only what the workload provably needs. Redpanda needs none of the defaults.
  • Scoped network (Network isolation): --network=none scores the full 15 but is wrong for a broker, producers and consumers must be able to connect to it. Any named or bridge network scores 4 of 15 (a WARN, not a fail): a connection path exists. This is the one dimension a broker cannot max out. Contain it anyway: attach a user-defined network scoped to just its producers and consumers, with no default route out, so a compromised broker cannot call arbitrary internet addresses.
  • --user 65532:65532 (Non-root user, already passing at +0): non-root already passes as the redpanda uid. Pinning an explicit fixed uid is the auditable choice and keeps volume ownership unambiguous; it does not change the score.
  • --read-only --tmpfs /tmp (Read-only rootfs, +10): make the root filesystem read-only and mount /var/lib/redpanda/data as an explicit writable volume. Removes the persistence surface.

Before and after

# Before: 63/100, grade C
docker run -d --name redpanda \
  redpandadata/redpanda:v24.2.11 \
  redpanda start --mode dev-container

# After: 89/100, grade B (scoped private network for producers and consumers)
docker run -d --name redpanda-hardened \
  --user 65532:65532 \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  --read-only --tmpfs /tmp \
  -v redpanda-data:/var/lib/redpanda/data \
  --network=redpanda-internal \
  redpandadata/redpanda:v24.2.11 \
  redpanda start --mode dev-container

Rescan: ironctl scan redpanda-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 broker exists to be connected to; network=none would score the last points but leave nothing able to reach the log. That is the honest ceiling for a broker, and it is a long way from the default C.

Verify it on your own broker

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

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

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

Keep going