Immutable Infrastructure Patterns

In this lesson, you will learn how to enforce the "Immutable Infrastructure" pattern by utilizing read-only root filesystems to harden container security.

The Philosophy of Immutability

In a traditional mutable environment, containers are treated like "miniature servers" that are patched, updated, and configured while running. Immutable infrastructure flips this: once a container is deployed, its filesystem should never change. By mounting the root filesystem as read-only, we neutralize an entire class of attacks—specifically those that rely on downloading malicious payloads, modifying configuration files, or installing backdoors into system directories like /bin or /etc during runtime.

Implementing Read-Only Roots

When you enforce a read-only root, you prevent the OverlayFS layer from creating new files or modifying existing ones in the container's upper directory. This eliminates the risk of unauthorized persistent changes.

Because applications often require some writable space for logs or temporary state, you cannot simply lock the entire filesystem. Instead, you map specific volatile directories to memory-backed tmpfs mounts. This allows the application to function while ensuring that all state is wiped the moment the container exits.

Consider this security configuration pattern for a container runtime:

# Example: Mounting a read-only container with specific writable exceptions
docker run --read-only \
  --tmpfs /tmp \
  --tmpfs /run \
  --mount type=tmpfs,destination=/var/log,tmpfs-size=512k \
  my-secure-app:latest

Why This Matters

By forcing the filesystem to be immutable, you achieve two primary security goals:

1. Attack Surface Reduction: An attacker who gains code execution cannot persist their presence by writing to the disk. Even if they modify a file in memory, that change vanishes upon restart.
2. Predictability: Since the filesystem state is fixed at build-time, you ensure that the runtime environment is identical to the testing environment, eliminating "configuration drift" where manual interventions lead to unpredictable security vulnerabilities.

This pattern complements the OverlayFS architecture by strictly preventing the creation of new whiteout files or modifications to the lower layers, effectively pinning the container to its original, verified state.

Key Takeaway: A read-only root filesystem, paired with targeted tmpfs mounts, transforms your container into an immutable unit that prevents runtime tampering and ensures long-term operational consistency.