Container Security
Suppose a network-facing image processor has a parsing vulnerability, and an attacker manages to execute code inside the container.
At that point, simply saying the application is “containerized” tells us very little. What matters is what the compromised process can actually do:
- Which user is it running as?
- Which host files are mounted?
- Which Linux capabilities does it have?
- Which system calls are allowed?
- Which internal services can it reach?
- Does container root have privileges on the host?
Container security is about reducing that access.
Assume the application may be compromised, then minimize the privileges, system calls, data, and network access available to it.
No single setting creates a perfect sandbox. Strong isolation comes from combining multiple independent security controls that limit the damage a compromised process can cause.
This chapter builds a container threat model around the shared kernel, then applies namespaces, rootless operation, non-root users, capabilities, no_new_privs, seccomp, mandatory access control, read-only filesystems, network policy, and verification.