Docker and Security. September 28, 2017 VASCAN Michael Irwin

Transcription

1 Docker and Security September 28, 2017 VASCAN Michael Irwin

2 Quick Intro - Michael Irwin Graduated (CS@VT); started full-time at VT Sept Started using Docker for QA June Attended first DockerCon August Deployed Summit (research admin app) First production IT project using Docker First IT project deployed on AWS Sept Started Blacksburg Docker Meetup Have met monthly since then March Recognized as Docker Captain

3 Any sufficiently advanced technology is equivalent to magic. - Arthur C. Clarke

4 In order to truly utilize any technology, you must first understand how it works and its motivations. - Someone, somewhere (me, now)

5

6 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 on host UTS - container gets its own hostname

7 Enough talk! Show me a container! github.com/soulwing/can

8 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

9 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

10 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

11 Let s run a Docker container!

12 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

13 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

14 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

15

16

17

18

19 One environment to rule them all

20 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)

21 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!

22 Simplified Application Patching

23 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)

24 Patch Demo!

25

26 Cattle, not Pets!

27 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

28 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

29 Orchestration!

30 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

31 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

32 Keep in touch! Twitter - mikesir@vt.edu Docker Blacksburg Meetup (or another one near your location) Docker Community Slack

33 Thanks! Any questions?