This lab focuses on understanding how Docker actually isolates workloads and where those boundaries become weak. Containers often appear similar to virtual machines at a glance, but their security model is very different.
The isolation provided by Docker relies on a combination of Linux primitives such as namespaces, cgroups, capabilities, and optional security profiles. Each of these layers contributes part of the containment model.
During the lab I examined what happens when containers run with default settings and then gradually modified those settings to observe the effect.
One useful exercise was inspecting running containers with:
docker inspect container_nameThe output contains a large amount of configuration detail that is often ignored. Looking at it from a security perspective reveals several important elements:
- Which Linux capabilities are enabled.
- Whether privileged mode is active.
- What mounts connect the container to the host.
- Which security profiles are applied.
Capabilities are particularly important. Docker drops several dangerous capabilities by default, but many deployments add them back without fully understanding their impact. The lab involved testing which capabilities were truly required for different workloads and then removing the rest.
I also explored seccomp and AppArmor profiles. The default profiles have improved significantly over time, but relying on defaults alone can still leave unnecessary system calls available.
Creating a custom seccomp profile forced me to look more closely at which syscalls an application actually needs. This exercise is tedious but extremely valuable when hardening production workloads.
The main takeaway from this lab is that container security depends heavily on configuration discipline. Docker provides strong building blocks, but they must be used intentionally.