Container Security: How We Got Here and Where We're Going
0 likes407 views
The document discusses the evolution of container security, highlighting significant advancements made in security features since Docker's inception. It outlines early security concerns, the development of features like image signing and user namespaces, and the transition towards a security-focused approach in the container ecosystem. Future directions include microservices-centric security, unprivileged containers, and enhancing cluster-level security management.
![A [Linux] Container Primer
5
pid mount
IPC
user network
uts
> Process Isolation
NAMESPACES
CGROUPS
> Resource Control](https://image.slidesharecdn.com/containersecurity-defragx20161-161116205200/85/Container-Security-How-We-Got-Here-and-Where-We-re-Going-5-320.jpg)
Container Security: How We Got Here and Where We're Going
- 1. Container Security >> How We Got Here and Where We’re Going
- 2. Who am I? Phil Estes Senior Technical Staff Member IBM Cloud, Open Technologies Container Strategy/Open Source Leader Docker community core engine maintainer < Linux/open source expertise for 15 years @ IBM < Community activities & accomplishments > Brought user namespace support to the Docker engine > Helped design v2.2 image specification with multi-platform support > Implemented first tool to create multi-platform images in Docker v2.3 registry > Member of the “Docker Captains” program 2
- 4. Always Be Isolating - We’ve been working to isolate processes for a very long time - Advent of OS era brought a level of isolation and control - Problems with shared substrate led to new ideas: - chroot, jails, zones - hardware virtualization - Linux namespaces & cgroups 4 Containers are our latest invention on the continuum between performance and (secure) isolation for our applications
- 5. A [Linux] Container Primer 5 pid mount IPC user network uts > Process Isolation NAMESPACES CGROUPS > Resource Control
- 6. How We Got Here - The right time - Linux kernel isolation primitives matured over a number of years (credit to LXC, OpenVZ, & many other Linux-centric container projects) - Readiness for application simplification plus distributed complexity - The right tools - Docker lowered entry friction to containerizing (packaging) an application - Docker API and client hid complexity of “getting it right” re: Linux kernel isolation - The right target - Developers were ripe for the efficiency improvement of dependency isolation per application 6
- 7. But...Is It Secure? Early Missing/Lacking Features: - Weak image format (Docker v1) - No image signing/verification - No multi-tenancy - Network security/isolation concerns - Tricky OS environment hardening 7 Early concerns lead to common deployment model of “double isolation”: containers deployed within VM isolation per application/tenant.
- 8. 2016: The Year of Container Security - Docker image format v2 - full content-addressability to image content - User namespaces - isolation from host ID use (especially root) - Seccomp - secure computing; filtering by Linux syscall - Docker Content Trust - image signing/provenance; configurable trust - No new privileges - container cannot elevate any Linux privilege/capability - PIDs limit - limits the number of processes spawnable by a container - Network security - fully encrypted control plane, encrypted SDN overlays - Pluggable AuthN/AuthZ - pluggable support for API access authorization - Lightweight VM - Intel Clear Containers/Hyper.sh, added KVM isolation - Vulnerability scanning - Docker, CoreOS, IBM, RH provide image scanning 8
- 9. Comparing the Field: The NCC Group Report 9 * NCC Group report “Understanding and Hardening Linux Containers”, v1.1, p. 97, section 9.13 > Users/packagers won’t turn on security if it’s difficult (LSM profiles are hard to write; seccomp, capabilities are complicated topics) > Sane defaults are tricky as well - someone’s app won’t work and they will complain > Docker tries to strike a balance (e.g. DCT off by default, allowance for insecure registries)
- 10. Container Security Futures - Microservices-centric security - Customized seccomp/AppArmor profiles based on application baseline - Alternatives and Tweaks - Unikernels? Different viewpoints about applicability - Fully unprivileged containers - Cluster-level Security Management - (Full) Multi-tenancy enablement - Bundling of security profiles and/or hinting for images - Cluster-specific security improvements (e.g. mutual TLS in Docker Swarm) - Linux Kernel & container engine maturity - User namespace next phase (per-container ID range isolation) - Namespaces and cgroups continue to mature/improve coverage 10
- 11. Unikernels - Compile your application and relevant pieces of the kernel substrate into a single bundle - Reduce attack surface area - Matches microservice model architecture - Docker integration means traditional Linux containers and unikernels can coexist in a solution - Not everyone on board with unikernel model 11
- 12. Unprivileged Containers - Removing the need for elevated (root) privilege through the entire process of requesting a container be started to completed container execution - Can be accomplished with setuid sidecar process today (lxc/lxd) - Work ongoing in the OCI (Open Container Initiative) community with runc to fully implement unprivileged containers - More work required in the Linux kernel as well - Main goal: reduce attack surface and any chance for elevated privilege to be exploited; unprivileged user can now create and execute a container 12
- 13. Application Security Tools - Application and image vulnerability scanning are a great first step towards visible security for the container ecosystem - Dockerbench and the NCC Group report provide detailed guidance on secure container engine configuration - But, users and administrators need more tools to help exploit new capabilities like AppArmor and seccomp. - These capabilities can be fine tuned specifically for an application, but expertise or tooling is required to enable this for the general user 13