A default container is not a security boundary — it runs as root, with a broad capability set and a writable filesystem, on a kernel it shares with the host. This chapter starts from the threat model that explains why the kernel is the blast radius, then strips each default away in turn: non-root, dropped capabilities, seccomp and the LSMs, a read-only filesystem, secrets out of the image, and finally a daemon that no longer runs as root. Driftwood's web container is the worked example, hardened layer by layer.
7 topics
Every other chapter in this course made Docker do something. This one makes it do less — deliberately. The reason is the fact you have carried since Chapter 1: a container shares the host's kernel, so a process that breaks out of its namespaces is on the host, not in a sandbox. A container escape is host compromise. The default configuration that ships out of the box is tuned for convenience, and convenience is the opposite of safe.
Defense in depth is the whole strategy. No single control stops a determined attacker, so you stack independent ones — run as a non-root user, drop the capabilities the workload never uses, confine syscalls and file access with seccomp and an LSM, make the root filesystem read-only, keep secrets out of the image, and drop the daemon's own root with rootless mode. Each layer assumes the one before it failed. The thread tying them together is least privilege: the smallest set of permissions, capabilities, syscalls, and writable paths the container needs to do its job, and nothing more.