If it’s in a container it’s secure right ?

Slide 1

Slide 1 text

If it’s in a container it’s secure right ? Scott Coulton Senior Software Engineer Puppet

Slide 2

Slide 2 text

@scotty-c @scottcoulton

Slide 3

Slide 3 text

This Talk What we will cover

Slide 4

Slide 4 text

Does the traditional infosec toolchain work efficiently in a world where a container’s average lifespan is 2 days? 4

Slide 5

Slide 5 text

Agenda How is container security different ? Does traditional security fit ? How to protect our container Protecting from the inside out Security and CD Can the 2 worlds live together Live demo 5

Slide 6

Slide 6 text

6 How is container security different ?

Slide 7

Slide 7 text

The way that traditional infosec approach is Reactive Containers allow you to be Proactive in your approach to infosec 7

Slide 8

Slide 8 text

Traditional Nessus, AV, HIDS New school AppArmor*, Clair, Notary * AppArmor is not new, I know. It is new for most people using containers I have spoken with 8

Slide 9

Slide 9 text

The risks. ● DoS the host (CPU, Memory or Disk) ● Fork Bomb ● Kernel modification ● Privilege Escalation 9

Slide 10

Slide 10 text

Just one! That’s all you need. (I am talking about process inside your container !!!) 10

Slide 11

Slide 11 text

Let’s protect our engine and runtime 11 ● Saine configurations for the Docker engine ● How to protect your Docker API ● How to protect the kernel of the OS ● Protect the container from unwanted process

Slide 12

Slide 12 text

Some sane defaults. ● Don’t run --pid host or --net host (without knowing the risks) ● Don’t bind your daemon to tcp://0.0.0.0:4243 ● Use TLS for all daemon traffic 12

Slide 13

Slide 13 text

If you know the process then apply AppArmor. 13

Slide 14

Slide 14 text

AppArmor example. 14

Slide 15

Slide 15 text

Infosec and continuous delivery. The myth ... 15

Slide 16

Slide 16 text

Add security to the pipeline 16

Slide 17

Slide 17 text

Make sure there is no vulnerabilities 17

Slide 18

Slide 18 text

Signing our images 18

Slide 19

Slide 19 text

A deployment flow 19

Slide 20

Slide 20 text

The full secure development pipeline. 20

Slide 21

Slide 21 text

Demo. https://github.com/scotty-c/dirty-cow-poc 21

Slide 22

Slide 22 text

http://csrc.nist.gov/publications/drafts/800-190/sp800-190-draft.pdf From Nist 22 A container-specific OS is a minimalist OS explicitly designed to only run containers, with all other services and functionality disabled, and with read-only file systems and other hardening practices employed. When using a container-specific OS, attack surfaces are typically much smaller than they would be with a general-purpose OS, so there are fewer opportunities to attack and compromise a container-specific OS. Accordingly, whenever possible, organizations should use container-specific OSes to reduce their risk. However, it is important to note that container specific OSes will still have vulnerabilities over time that require remediation.

Slide 23

Slide 23 text

This will change the way you think about truly immutable infrastructure Enter LinuxKit 23

Slide 24

Slide 24 text

So what does LinuxKit give us ? LinuxKit 24 ● Lean OS. Minimal size, minimal boot time ● 4.9 Kernel ● Allows you to run any container runtimes ● Batteries included but can be replaced ● All system services are containers

Slide 25

Slide 25 text

Why is it different to a traditional OS ? LinuxKit 25 ● Smaller attack surface ● Immutable infrastructure ● Sandboxed system services ● Specialized patches and configurations ● You have full control over the build ● The configuration is all yaml

Slide 26

Slide 26 text

Why is it different to a traditional OS ? LinuxKit 26 kernel: image: "linuxkit/kernel:4.9.x" cmdline: "console=ttyS0 console=tty0 page_poison=1"

Slide 27

Slide 27 text

It runs on ? LinuxKit 27 ● Desktop, Server, IoT, Mainframe ● Intel & ARM (and others) ● Bare Metal & Virtualized ● On-premises & in the Cloud