Lesson 3.12: Running containers safely
Containers share the host's kernel, so the isolation between a container and its host depends on how it's started. A privileged container, extra Linux capabilities, the host's Docker socket mounted inside, or host networking each remove part of that wall, and an attacker who breaks into the app can step onto the host. In the lab you audit how Northwind's three containers run, find that the API container has almost no isolation at all, stop it, and read the hardened run command that will replace it.
17 min
You will learn to
- Explain why runtime settings matter
- Detect privileged containers
- Recognise the Docker socket mount
- Read capabilities and read-only settings
- Describe a hardened docker run
Key terms
- Privileged container
- A container started with --privileged: all capabilities and access to host devices; effectively root on the host.
- Linux capabilities
- Root's powers split into pieces that can be added or dropped per process.
- Docker socket
- /var/run/docker.sock, the API of the Docker engine; mounting it in a container gives control of the host.
- Container escape
- An attacker breaking out of a container onto the host.
- Read-only root filesystem
- Running a container whose filesystem can't be modified, except explicit writable mounts.
← Thresholds and baselines · All lessons · Password policy and breached passwords →