Docker and Security September 28, 2017 VASCAN Michael Irwin
Quick Intro - Michael Irwin 2011 - Graduated (CS@VT); started full-time at VT Sept 2015 - Started using Docker for QA June 2016 - Attended first DockerCon August 2016 - Deployed Summit (research admin app) First production IT project using Docker First IT project deployed on AWS Sept 2016 - Started Blacksburg Docker Meetup Have met monthly since then March 2017 - Recognized as Docker Captain
Any sufficiently advanced technology is equivalent to magic. - Arthur C. Clarke
In order to truly utilize any technology, you must first understand how it works and its motivations. - Someone, somewhere (me, now)
A container is... NOT a VM, but simply an isolated process Isolation is provided by kernel namespaces Process - PID 1 in container may be PID 3753 on host Network - container can have its own network interfaces/ip address/sockets Mount - container can have its own root filesystem/mountpoints User - root/user ID 1 in container may actually be user ID 10976 on host UTS - container gets its own hostname
Enough talk! Show me a container! github.com/soulwing/can
VMs vs Containers App 1 App 2 App 3 Bins/Libs Bins/Libs Bins/Libs Guest OS Guest OS Guest OS Hypervisor App 1 App 2 App 3 Bins/Libs Bins/Libs Bins/Libs Host Operating System Operating System Infrastructure Infrastructure
The container recipe A root filesystem Networking setup... To let the container talk to the world To let one container talk to others To expose ports from container to host Various namespaces Launch the initial command Clean things up afterwards
Introducing Docker Docker provides an integrated technology suite that enables development and IT operations teams to build, ship, and run applications anywhere. Build - package an application with its dependencies and environment Ship - share the package with all deployment environments Run - run, scale, and monitor your application
Let s run a Docker container!
Docker Images Every image contains a manifest and a collection of layers Each layer consists of... Metadata (json) - container config, reference to parent layer, etc A tarball of filesystem diffs
Using Layers Layers can be reused by multiple children Provides ability to have common base layers Since each layer is immutable, only one copy is needed Reduces both registry and local storage requirements App 1 App 2 Tomcat App 3 Wildfly OpenJDK 9 App 4 App 5 PHP 7.1 PHP 5.6 Apache httpd 2.4 Alpine Base Image
Creating Docker Images Preferred method is to create a Dockerfile Text-based script with commands to configure/create filesystem layers Allows it to be version controlled with a project Each command ends up being another layer in the Dockerfile Multi-stage builds allow final images to contain only runtime dependencies FROM mvn:3.5-jdk8 AS build WORKDIR /app COPY.. RUN mvn package FROM tomcat:7-jre8-alpine COPY --from=build /app/target/*.war /usr/local/tomcat/webapps
One environment to rule them all http://lotrminecraftmod.wikia.com/wiki/file:the-one-ring.jpg
Consistency in all Tiers Development CI/CD Server Developer pulls environment images and code Performs development in environment Pushes code Builds code and runs automated test suites Produces image using same environment base, but with build artifact added Push to image registry Staging/Production Images pulled on to various infrastructure (on-prem/cloud/hybrid)
Doing development in containers... Forces earlier collaboration with sysadmins Do you actually trust your devs to come up with safe base images? Gives confidence that the app will work the same everywhere Has allowed Summit to be deployed 49 times in the last year Images in registries can then be scanned for vulnerabilities!
Simplified Application Patching https://www.youtube.com/watch?v=k37g2j0k8ba
Updated Patch Model No longer need to go to each individual machine and patch Simply update images to point to patched parent App 1 Tomcat App 2 App 3 Wildfly App 1 Tomcat OpenJDK 9 (VULNERABLE!!) Alpine Base Image App 2 App 3 Wildfly OpenJDK 9 (PATCHED)
Patch Demo!
Cattle, not Pets!
Leaner Hosts! Hosts only need to run containers Reduces potential attack vectors Reduces number of things that need to be patched Makes host machines easily replaceable No need to have direct access to the machine to "make tweaks" Lock yourself out of production "Use container-specific host OSs instead of general-purpose ones to reduce attack surfaces. When using a container-specific host OS, attack surfaces are typically much smaller than they would be with a general-purpose host OS, so there are fewer opportunities to attack and compromise a container-specific host OS. Accordingly, whenever possible, organizations should use container-specific host OSs to reduce their risk. However, it is important to note that container-specific host OSs will still have vulnerabilities over time that require remediation." -NIST draft Application Container Security Guide
New Hosts with Every Deploy! (why not?) Deployment (and patching) becomes Spin up new hosts Start containers on new hosts Transfer traffic to new containers Burn down old machines
Orchestration!
Some best practices... Base from official images as much as possible Keep images as minimal as possible Use --privileged very, very sparingly Install only what you need Use multi-stage builds to keep final images focused Treat such a container as any other process running as root Run containers in read-only mode (if possible) Limit user capabilities by using AppArmor, seccomp, SELinux Sign images when pushing to repos using Use Docker Bench benchmark to evaluate container host security
Get Started! Start experimenting you re already doing most of the work You don t need to do everything Day One Still deploy on the hosts you re using, but move artifacts using Docker
Keep in touch! Twitter - @mikesir87 Email - mikesir@vt.edu Docker Blacksburg Meetup (or another one near your location) Docker Community Slack
Thanks! Any questions?