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

Talk from Container Camp 2017 https://2017.container.camp/

Transcript

1. If it’s in a container it’s secure right ? Scott Coulton Senior Software Engineer Puppet
2. @scotty-c @scottcoulton
3. This Talk What we will cover
4. Does the traditional infosec toolchain work efficiently in a world where a container’s average lifespan is 2 days? 4
5. 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
6. 6 How is container security different ?
7. The way that traditional infosec approach is Reactive Containers allow you to be Proactive in your approach to infosec 7
8. 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
9. The risks. • DoS the host (CPU, Memory or Disk) • Fork Bomb • Kernel modification • Privilege Escalation 9
10. Just one! That’s all you need. (I am talking about process inside your container !!!) 10
11. 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
12. 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
13. If you know the process then apply AppArmor. 13
14. AppArmor example. 14
15. Infosec and continuous delivery. The myth ... 15
16. Add security to the pipeline 16
17. Make sure there is no vulnerabilities 17
18. Signing our images 18
19. A deployment flow 19
20. The full secure development pipeline. 20
21. Demo. https://github.com/scotty-c/dirty-cow-poc 21
22. 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.
23. This will change the way you think about truly immutable infrastructure Enter LinuxKit 23
24. 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
25. 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
26. 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"
27. It runs on ? LinuxKit 27 • Desktop, Server, IoT, Mainframe • Intel & ARM (and others) • Bare Metal & Virtualized • On-premises & in the Cloud
28. LinuxKit Demo. 28
29. Questions. 29