Container Security

>> How We Got Here and Where We’re Going

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

Motivation

MISINFORMATIONMULTI-

VENDOR/OS WORLD

FASTMOVING

ECOSYSTEM

3

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