container security: how we got here and where we're going
Post on 15-Apr-2017
269 Views
Preview:
TRANSCRIPT
Who am I?
Phil EstesSenior Technical Staff MemberIBM 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
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
A [Linux] Container Primer
5
pid mount
IPC
user network
uts
> Process Isolation
NAMESPACES
CGROUPS
> Resource Control
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- A familiar role that VM isolation took a decade ago
6
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.
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
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)
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
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
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
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
Thank You! ...Questions?
14
@estesp
github.com/estesp
estesp@gmail.com
https://integratedcode.us
IRC: estesp
top related