How would you run a Docker container whose filesystem is immutable except for the few paths that genuinely need to be written, and what does marking an individual mount read-only actually enforce?

## Two different knobs Candidates often blur these together, and the interviewer is usually checking whether you can separate them. 1. **`--read-only`** is a container-level flag. It mounts the container's root filesystem read-only, so the image layers *and* the container's thin writable layer become immutable. Explicit mounts you attach (volumes, binds, tmpfs) are not affected — they keep whatever mode they were given. 2. **A read-only mount** is per-mount: `-v src:dst:ro`, `--mount ...,readonly`, or Compose's `read_only: true` on a long-syntax entry. It says "this particular filesystem is not writable from inside this container". You almost always use them together: lock the root, then decide path by path what gets opened and in which mode. ## Building the pattern Start from `--read-only` and let the app tell you what it needs. Typical result: - `--tmpfs /tmp:size=64m,mode=1777` — nearly every runtime, library and shell tool expects a writable `/tmp`. - `--tmpfs /run:size=16m` — PID files, unix sockets, and anything that follows the FHS for runtime state. Nginx also wants its cache directories; Java may want a writable `/tmp` for the perf/hsperfdata files unless disabled. - A **named volume** on the one directory that holds real state (`/var/lib/app`), read-write. This is the data you back up. - **Read-only bind mounts** for injected material: `/etc/app/config.yaml:ro`, `/etc/ssl/certs:ro`. Config the container reads but must never rewrite is exactly the case for `:ro`. The payoff is concrete: an attacker with code execution cannot persist a payload in the image filesystem, cannot rewrite the config to point at their own endpoint, and any tampering they achieve dies with the container. It also surfaces sloppy applications that scribble into their install directory, which is worth knowing before production does. ## What read-only actually enforces — and does not - **Scope is this container's mount namespace.** A read-only bind mount does not make the host directory read-only. The host, and any other container that mounts the same path read-write, can still change the content, and the read-only container will see those changes. `:ro` is a guarantee about *who may write*, not about *what the data will be*. - **It is not integrity.** If you need the config to be unchanged, you need signing or checksums; a read-only mount only stops this container from being the one that changes it. - **Recursion caveat.** A bind mount is a mount of one point, and historically the `ro` flag applied to that mount but not to submounts already present under the source path — a nested mount could remain writable inside a nominally read-only bind. Modern Docker on a recent kernel supports recursive read-only binds; `--mount type=bind,bind-recursive=readonly,...` makes the intent explicit. If you are relying on read-only for a security property over a path with nested mounts, check this rather than assuming. - **Volumes can be read-only too.** `-v appdata:/var/lib/app:ro` is legitimate — for example a sidecar or exporter that reads another container's data without being able to corrupt it. Note the seeding interaction: an *empty* volume mounted read-only never gets populated in a useful way, so seed it from a writer first. - **Root can sometimes remount.** A container process running as root with `CAP_SYS_ADMIN` may be able to remount paths; read-only mounts pair with dropping capabilities and running as a non-root user rather than replacing them. ## Making it stick Do it in the deployment definition, not by convention: `read_only: true` plus `tmpfs:` and `:ro` bind entries in Compose, so the property is reviewable in a diff. Verify with `docker inspect --format '{{json .Mounts}}'` (each mount reports `RW: true/false`) and by shelling into the container and attempting a write — the failure mode you want is a clean `Read-only file system` error, at start time, not a surprise in production. Expect to iterate once: most images need one or two writable paths you did not predict, and finding them is the actual work of adopting the pattern. ## Summarising for the interviewer "`--read-only` for the root, tmpfs for scratch, one named volume for state, `:ro` binds for injected config — and I know `:ro` binds only this container, so the host can still change the data underneath it." That sentence covers the mechanic, the pattern and the limitation.