2.9. Recap

We saw how to run containers and how to secure them avoiding root, dropping capabilities, mounting filesystems read-only, and using Linux Security Modules such as seccomp. However it is important to say that because of the architecture of docker, anyone who can start a container has more privileges on the host.

It is still important to secure the Host Operating system and maybe to run a deamonless container technology like podname. What we did not touch are things like network security and monitoring. More on that in the Kubernetes Security lab.

Addendum: Most Common Container Escape Techniques

Well we learned alot about defense and saw some common attacks (runc vulnerabilities, kernel vulnerabilites, user mode helper (deprecated), kernel module insertion, docker sockets…). What else are common pattern?

SUID Privilege Escalation via Shared User Namespace

If a container shares a user namespace with the host, an attacker can create a SUID binary in a mounted directory.
When executed on the host, that binary retains its SUID bit, allowing privilege escalation to root.

Sensitive Host Mounts

Containers sometimes mount sensitive host directories (e.g., /etc, /root, /var/lib/docker).
Attackers can directly read or modify host files if these mounts are writable or misconfigured.
This is a misconfiguration-based escape rather than a vulnerability.

Final Thoughts

Secured Containers

This was it for Container Security, you should have now the necessary knowledge to build & run containers and container infrastructure.

Now on to Kubernetes Security.