Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Security Tips to run Docker in Production

2,093 views

Published on

When you are designing a production environment security is essential. All the Docker ecosystem but in particular Docker Swarm allows us to ship our containers out of our laptop, how can we make this process safe? During my talk, I will share tips around production environment, immutability and how troubleshooting common attack as code injection with Docker. Static analysis of our images, content trust with Notary to make our journey secure.
How can we setup a cluster on the main cloud providers with VPN and node labeling to expose only a portion of our cluster? I will also show what Docker provides (Content Trust, Static Analysis) but also open source alternatives as Notary, centos/clair and Cilium.
In the end of this talk, we had a better idea around how manage Docker in production.

Published in: Technology

Security Tips to run Docker in Production

  1. 1. Docker and Container Security @gianarb
  2. 2. Hello! I am Gianluca Arbezzano Site Reliability Engineer at InfluxDB oss maintainer and Docker Captain You can find me: @gianarb on Twitter and GitHub
  3. 3. Play Safe - a free ebook about Container Security. What? I wrote an ebook ~55 pages about Docker and Container Security. It comes from my daily experience deploying and making containers secure. CoreOS Clair, Apparmor, SwarmKit, Notary, Cilium and a lot more... Get it http://scaledocker.com Leave your email and you will receive the ebook.
  4. 4. Make it easy to do the secure things Otherwise your colleagues will be the perfect vulnerability.
  5. 5. Least Privileged It’s valid for Orchestration and anything else.
  6. 6. 1. Runtime Apparmor, Seccomp, SELinux
  7. 7. 2. Static Image Scan, CoreOS Clair
  8. 8. 3. Update Injection new code in the system.
  9. 9. There is always more. Port :80 / :443 Anything else.. Services, libraries, Kernel, Operations, continuous delivery and so on..
  10. 10. VPN is not that complicated anymore. https://community.openvpn.net/openvpn/wiki/BridgingAndRouting
  11. 11. SELinux 1. Everything inside a system has labels 2. By default everything is denied 3. You can write policy to allow only what you need.
  12. 12. AppArmor #include <tunables/global> profile sample-one flags=(attach_disconnected,mediate_deleted) { #include <abstractions/base> network, capability, file, umount, deny /etc/** w, }
  13. 13. AppArmor docker run --security-opt=”apparmor:sample-one” --rm -it alpine /bin/sh deny /etc/** w touch /tmp/hello.txt touch /etc/bad.txt touch: /etc/ciao: Permission denied
  14. 14. “ AppArmor profile pull requests is the bane of my existence Cit. Jess Frazelle https://github.com/jessfraz/bane
  15. 15. It’s easy if you run one process for every container!
  16. 16. And if you know what you are running.
  17. 17. Cilium - github.com/cilium/cilium
  18. 18. Cilium - github.com/cilium/cilium docker network create --ipv6 --subnet ::1/112 --ipam-driver cilium --driver cilium cilium
  19. 19. Cilium - github.com/cilium/cilium docker run -d --name server --net cilium --label io.cilium.service.server alpine sleep 30000 docker run -d --name client --net cilium --label io.cilium.service.client alpine sleep 30000
  20. 20. Cilium - github.com/cilium/cilium docker run -d --name server --net cilium --label io.cilium.service.server alpine sleep 30000 docker run -d --name client --net cilium --label io.cilium.service.client alpine sleep 30000
  21. 21. Cilium - github.com/cilium/cilium $ cilium endpoint list
  22. 22. docker exec -it client ping server sudo cilium monitor Cilium - github.com/cilium/cilium
  23. 23. cilium policy allowed -s cilium:io.cilium.service.client -d cilium:io.cilium.service.server Resolving policy for context &{Trace:1 Logging:0xc42177b590 From:[cilium:io.cilium.service.client] To:[cilium:io.cilium.service.server]} Root rules decision: undecided No matching children in io.cilium Root children decision: undecided Final tree decision: deny Cilium - github.com/cilium/cilium
  24. 24. "name": "service", "children": { "client": { "name": "client"}, "server": { "name": "server", "rules": [{ "allow": [{ "action": "accept", "label": { "key": "host", "source": "reserved" } }, { "action": "accept", "label": { "key": "../client", "source": "cilium" }
  25. 25. BPF - github.com/cilium/cilium BPF is a highly flexible and efficient virtual machine-like construct in the Linux kernel allowing to execute bytecode at various hook points in a safe manner. It is used in a number of Linux kernel subsystems, most prominently networking, tracing and security http://cilium.readthedocs.io/en/latest/bpf/
  26. 26. Images. There are a lot of good practices and mistake to make.
  27. 27. FROM debian Oh this seems too much...
  28. 28. FROM scratch Yes. I will make debugging with my magic wand.
  29. 29. FROM centos Yum let’s go for lunch! I am hungry
  30. 30. This decision requires strong opinions... Let’s keep in mind about some concerns
  31. 31. 1. Size Unused files, libraries, packages makes your image bigger.
  32. 32. 2. Security Unrequired code and files are a good way to get free vulnerabilities!
  33. 33. 3. Debugging At some point you will be happy to run `ping google.com`.
  34. 34. LinuxKit can help But maintaining your distro is not very common yet.
  35. 35. Docker Scan
  36. 36. COREOS Clair 1. In regular intervals, Clair ingests vulnerability metadata from a configured set of sources and stores it in the database. 2. Clients use the Clair API to index their container images; this parses a list of installed source packages and stores them in the database. 3. Clients use the Clair API to query the database; correlating data is done in real time, rather than a cached result that needs re-scanning. 4. When updates to vulnerability metadata occur, a webhook containing the affected images can be configured to page or block deployments.
  37. 37. The update can be a problem sometime...
  38. 38. Docker content trust. The world behind the pull.
  39. 39. GPG, TLS, SHA What I need more?
  40. 40. SHA1 - First collision https://security.googleblog.com/2017/02/ announcing-first-sha1-collision.html
  41. 41. GPG limitation ● Is it coming from the place where I hope? ● Between the sender and the receiver what happen? ● Are the signatures too old?
  42. 42. TUF - The update framework https://theupdateframework.github.io
  43. 43. The framework is inspired by Thandy the Tor’s secure updating system
  44. 44. Main principles: ◎ Responsibility Separation to decrease the scope of a specific role. ◎ Survivable key compromise and scoped keys. ◎ Multi-Signature thresholding
  45. 45. It doesn’t manage your packages It only manage identity and signatures in a separate location.
  46. 46. Roles: ● Root ● Targets ● Shanpshot ● Timestamp ● Delegation
  47. 47. Notary https://github.com/docker/notary
  48. 48. dockerd -H fd:// -H tcp://10.7.5.22 --label kind=private
  49. 49. echo ’{"username":"root", "password": "root"}’ > ~/secret-test.json docker secret create myapp -f ~/secret-test.json docker service create --name backend --secret myapp --image gianarb/micro:1.2.0 Secret available at /run/secret/myapp Distributed Secret
  50. 50. docker network --opt encrypted --driver overlay tick-net Network Encryption
  51. 51. $ docker swarm init --advertise-addr 10.0.0.1 --datapath-addr 192.168.0.1 Separate interface for control and data traffic
  52. 52. Immutability
  53. 53. $ docker diff ciccio C /var A /var/www A /var/www/index.html A /var/www/spy.html Analysis post running
  54. 54. Containers are not magic. Bad code stays bad.
  55. 55. Write good code
  56. 56. Thanks! Any questions? @gianarb

×