Hardening Docker Containers for Production: Enforcing Non-Root Users and Immutable Filesystems

Quick Summary / Direct Answer: Hardening Docker containers for production requires running application processes as unprivileged non-root users and locking down the container root filesystem to read-only mode using --read-only or the read_only: true compose directive. This architecture neutralizes privilege escalation vectors and blocks runtime payload persistence.

Key Takeaways:

• Default Docker configurations run as root inside the container, exposing the underlying host kernel to full container breakout exploits.
• Enforcing non-root execution via the USER instruction in Dockerfiles prevents unauthorized system modification during runtime.
• Immutable root filesystems force applications to use explicit, ephemeral volumes for logs and state, stopping malicious payload drops.

The Root Problem with Default Container Executions

Most developers spin up a container, run their code, and call it a day. It works. The CI pipeline passes. Then it hits staging. When a container runs as root, any arbitrary remote code execution vulnerability immediately yields total control over the container user namespace. From there, namespace breakout techniques or unpatched kernel vulnerabilities can compromise the host machine. We have seen this happen in enterprise audits repeatedly. A single misconfigured npm package or vulnerable python library turns into a cluster-wide incident because the process held UID 0.

We need a systematic baseline. Security isn’t an afterthought bolted on at the deployment phase; it starts at line one of your multi-stage Dockerfile.

Enforcing Non-Root Users in Multi-Stage Builds

Creating a non-root user requires explicit declaration. Don’t rely on runtime flags alone. Bake the security constraints directly into your image architecture. Here is a production-grade multi-stage Dockerfile demonstrating how to compile assets as root and execute runtime processes as an unprivileged user.

# Stage 1: Build dependencies and binaries
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY . .
RUN go build -o /app/bin/server ./cmd/server

# Stage 2: Runtime image
FROM alpine:3.19
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
WORKDIR /app
COPY --from=builder /app/bin/server /app/server
USER appuser
EXPOSE 8080
ENTRYPOINT ["/app/server"]

Notice the sequence. We create the group and user via Alpine’s addgroup and adduser utilities before copying our binary. Finally, the USER appuser instruction drops privileges permanently before the entrypoint executes. If an attacker gains command execution inside this container, they hit a brick wall. They cannot install packages via apk, modify system files, or touch restricted system resources.

Locking Down the Root Filesystem

Running as a non-root user stops modification of system binaries, but what about application-level data directories? Malicious payloads often write dropped scripts to /tmp or the application root. To solve this, we make the entire container root filesystem immutable.

An immutable filesystem treats the container image as read-only. Applications needing to write state, logs, or temporary caches must mount specific tmpfs volumes or persistent volumes. Let’s look at how container runtimes manage these security boundaries compared to standard defaults.

When deploying this via Docker Compose, you enforce immutability with explicit volume overrides and read-only flags:

services:
  web:
    image: my-secure-app:latest
    read_only: true
    user: '10001:10001'
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    tmpfs:
      - /tmp:size=64M,noexec,nosuid,nodev
      - /var/cache/nginx:size=128M,noexec,nosuid,nodev
    volumes:
      - app-data:/app/data

That tmpfs block is vital. By mounting /tmp with noexec, nosuid, and nodev, we prevent attackers from executing any binary dropped into temporary directories, even if they bypass application-level validation checks.

Troubleshooting Common Filesystem and Permission Failures

When you first apply a read-only filesystem, your application will likely crash. It’s expected. Modern frameworks love writing logs, PID files, or cache data directly to the current working directory or system paths like /var/log.

Here is the debugging workflow we use in enterprise clusters when a hardened container fails upon startup:

1. Inspect Error Logs: Look for permission denied errors or read-only file system exceptions in standard output.
2. Identify Write Paths: Determine exactly which directories the application framework attempts to write to. Common culprits include node_modules/.cache, vendor/, or local SQLite database paths.
3. Redirect or Mount: Configure environment variables to point caches to /tmp, or declare dedicated tmpfs mounts for those specific paths in your compose or Kubernetes manifest.

Frequently Asked Questions

Does a read-only root filesystem degrade container performance?
No. In fact, it can marginally improve I/O performance by eliminating overlayfs copy-on-write overhead for writes directed to temporary in-memory tmpfs mounts.

How do I handle applications that insist on writing to /var/run or /app?
Refactor the application configuration via environment variables to point runtime directories to /tmp, or overlay a dedicated tmpfs mount over that specific directory path.

The Bottom Line: Actionable Next Steps

Security hardening is an iterative engineering discipline, not a checkbox. Start by auditing your existing Dockerfiles for missing USER instructions. Next, introduce read_only: true to your staging environments and fix the resulting write errors by mapping appropriate tmpfs volumes. Finally, drop all Linux capabilities and enable no-new-privileges across your entire fleet.