Explore container security and isolation techniques in this conference talk from Derbycon 2018. Delve into the misconception of containers as sandboxes and learn about real-world workload isolation. Examine container isolation models using cgroups and namespaces, including Docker, Rkt, and LXC. Discover the Open Container Initiative (OCI) specification and its role in defining image and runtime attributes. Investigate advanced isolation methods such as gVisor user-space kernel and Kata Containers with hypervisor integration. Address implementation flaws like account reuse in Kubernetes and the importance of network policies. Learn about beneficial design patterns, including the No New Privileges flag and read-only containers. Gain insights into building effective security policies and understand the complexities of container isolation beyond runtimes.
Overview
Syllabus
Living in a Secure Container, Down
In the Beginning
Spoiler: Containers Aren't Sandboxes
Isolating Container Workloads, IRL
The Gateway Drug
Container Isolation Models Via cgroups & namespaces Docker, Rkt, LXC
Open Container Initiative (OCI) Spec • Defines image and runtime attributes
Control Groups & Namespaces By UID, GID, PID
gVisor User-space Kernel
Kata Containers + Hypervisor Previously Intel Clear Containers Container runtime executes within a true hypervisor Provides an extra layer of isolation between the container and host OS
Implementation Flaw - Account Reuse By default, K8s uses the namespace default service account if you don't define one for your pod.
Network Policies This is often a good problem to solve at the orchestration layer. Restrict egress traffic by default and whitelist exceptions
Leveraging Good Design Patterns
No New Privileges Introduced in Linux 3.5, uses the no_new_privs kernel flag
Read-Only Containers Prevents writing to the root filesystem Reduces an attacker's ability to modify files and/or elevate privileges
Building Policies How many of your Java developers understand SELinux?
Conclusion Container isolation goes beyond the runtimes themselves
