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

Quick Summary / Direct Answer: Hardening Docker containers for production requires transitioning away from default root execution and writable root filesystems. By explicitly setting a non-root user via the USER directive and mounting container filesystems as read-only with targeted tmpfs volumes for runtime state, you eliminate entire vectors of privilege escalation and remote code execution exploits.

Key Takeaways:

• Running containers as root grants attackers immediate host namespace access if a kernel vulnerability or container breakout occurs.
• Read-only root filesystems prevent attackers from writing malicious binaries, persistence mechanisms, or web shells during an RCE event.
• Effective container lockdown combines non-root execution, read-only mounts, capability dropping, and selective tmpfs configurations.

The Root User Trap in Container Architecture

By default, Docker builds and runs your containers as the root user. It is convenient. It lets you write files anywhere, install packages on the fly, and bypass permission errors without thinking twice. It is also a catastrophic security failure waiting to happen in production.

When an application runs as root inside a container, it often runs as root on the host’s underlying Linux kernel namespace if user namespaces aren’t strictly configured. If an attacker discovers an injection vulnerability or achieves remote code execution through an unpatched dependency, they don’t just own the process. They own the container. From there, escaping to the host kernel is frequently just a matter of time.

We see this mistake in enterprise codebases constantly. Developers spin up Node.js, Python, or Go microservices straight from standard base images without dropping privileges. When deploying this at scale across Kubernetes or ECS clusters, that single oversight turns a localized application bug into a cluster-wide emergency.

Enforcing Non-Root Execution

Fixing the user problem isn’t just about adding a USER instruction in your Dockerfile. It requires planning around file ownership, directory permissions, and system UID mappings. If your application tries to write logs to /var/log or cache data in /app/cache, a non-root user will crash immediately with permission denied errors.

Here is how a hardened production Dockerfile looks in practice:

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json .
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app

# Create a dedicated non-root user and group
RUN addgroup -g 1001 -S appgroup && \
    adduser -u 1001 -S appuser -G appgroup

COPY --from=builder --chown=appuser:appgroup /app/dist ./dist
COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules
COPY --from=builder --chown=appuser:appgroup /app/package.json ./package.json

USER appuser
EXPOSE 3000
CMD ["npm", "start"]

Notice the explicit creation of system UIDs and GIDs. Using numeric IDs rather than usernames helps orchestrators like Kubernetes validate security contexts instantly without relying on name resolution inside the container runtime.

Locking Down the Filesystem

Stopping root execution is only half the battle. Even as a non-root user, an attacker with RCE can download malicious scripts, modify application source files, or drop compiled binaries into writable directories like /tmp or /var/tmp if they aren’t properly constrained.

The antidote is a read-only root filesystem. By forcing the container filesystem to be read-only, you strip away the ability to write to disk entirely. If the application needs scratch space to write temporary files, you explicitly mount isolated memory-backed tmpfs volumes.

Security Posture Comparison

Configuring Read-Only Mounts and Tmpfs

When running your container engine or orchestration platform, you enforce the read-only flag alongside targeted tmpfs mounts for operational directories. Here is how you execute this via Docker CLI:

docker run -d \
  --name secured-service \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  --tmpfs /app/temp:rw,noexec,nosuid,size=128m \
  --user 1001:1001 \
  --cap-drop=ALL \
  my-hardened-image:latest

Every single flag here plays a specific defensive role. The --read-only flag locks the container root. The tmpfs mounts provide scratch pads while explicitly applying noexec (preventing execution of binaries from temporary directories) and nosuid (preventing setuid/setgid bit manipulation). Dropping all capabilities with --cap-drop=ALL ensures the process retains zero privileged kernel operations.

Frequently Asked Questions

Why does my application crash with ‘permission denied’ after setting a non-root user?

This happens when files or directories copied during the build stage retain root ownership, or when the application attempts to write to paths outside designated writable volumes. Ensure you use the --chown flag during COPY instructions and map necessary writable paths to tmpfs or persistent volumes.

Can I run a read-only container if my application writes log files to disk?

Yes. Production best practices dictate that modern applications should output logs directly to stdout and stderr, allowing the container runtime to capture them. If your legacy software insists on writing physical log files, mount a dedicated tmpfs volume specifically for the log directory.

The Bottom Line: Actionable Next Steps

Hardening your container fleet is an iterative engineering discipline, not a one-time checkbox. Start by auditing your base images for root usage using static analysis tools in your CI pipeline. Next, introduce the USER directive and test your application functional suites. Finally, roll out --read-only filesystems combined with tmpfs mounts across staging environments before pushing to production clusters.