Agenda Intro Why use containers at all? Linux Kernel: a pop of history Docker and friends Host Security Container Security Building secure images Questions?
Why use containers at all?
Why use containers? Repeatable environment Isolation Fast startup Run anywhere Small, deployable units
Linux kernel: a pop of history
Origins of container technology
Linux Kernel chroot Added to Unix in 1979 Changes apparent root directory for processes
Linux Kernel Namespaces Added in 2002 by employees at IBM Allow for kernel resource partitioning Provide processes with their own view of the system
Linux Kernel Mount Namespace Host file systems OverlayFS
Linux Kernel PID Namespace Independent process IDs First process gets PID 1 lifecycle tied to that
Linux Kernel Network Namespace Isolated network stack IP Routing Firewall
Linux Kernel IPC Namespace SysV Interprocess Communication Commonly use shared memory between processes
Linux Kernel UTS Namespace Allows control of hostname / domain
Linux Kernel User Namespace Privilege isolation Shifts User Identification
Linux Kernel cgroups Added in 2007 by employees at Google Allow for kernel resource limiting Work on groups of processes Single container per group
Docker and friends
Docker and friends Docker Released 2013 Internal project at dotCloud Over 1200 contributors Cisco, Google, Huawei, IBM, Microsoft, and Red Hat
Docker and friends Docker Developer focused Dockerfile FS Layers 160% rise in 2016 alone
Docker and friends Docker Troubles Docker Inc. Fast moving APIs libcontainer
Docker and friends CoreOS rkt OCI Multiple Stages kvm/hypervisor based container runtime introduces concept of pods
Docker and friends runc OCI
Host Security
Host Security Standard rules apply Minimize access Up to date kernel Hardened
Host Security Minimize Attack Surface Container have limited host requirements no build tools no debuggers
Container Security
Container Security Container Scanning Static analysis virus scanning
Container Security Container Signing Ensures image integrity Only allow signed images in production
Container Security ReadOnly Root Running image cannot be mutated Primarily useful in stateless images
Container Security NonRoot User Switch user as soon as possible in build Ensures container breakout doesn’t attain root Slightly less critical with the adoption of user namespaces
Container Security Minimal Images Smaller surface area Less software to become stale
Building secure images