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.

Docker security: Rolling out Trust in your container


Published on

State of Docker Security and newly released Docker CONTENT TRUST explained

Published in: Engineering
  • Be the first to comment

Docker security: Rolling out Trust in your container

  1. 1. Ronak Kogta Docker Security Rolling out trust in your container
  2. 2. Buzz is catching on, and so is technology Neatly packs multiple applications on one operating system Gives you way to compose clusters, manage them and play with them at the scale of 100,000 Docker Docker Docker
  3. 3.  A very secure system which is not user-friendly will not be secure for long. (because people will find a way to go around it)  Usable Security is a principle of building security systems while considering human workflows.  Speed  Efficiency  Learnability  Memorability  User Preference Idea of Usable Security
  4. 4. Its going to be everywhere  Your Desktop, Workstation & Cloud Infrastructure.  Your Production, Development & Testing Cycles. It is going to be used by everyone  Your team, clients, and partners.  Independent developers and teams who are using your images. We should definitely think about #docker-security Docker Space
  5. 5.  How safe is docker isolation ?  If some malicious user has docker daemon access, what to do ?  Can I use security policies over docker ?  SELINUX,APPARMOR,GRSEC  Can I really trust docker image I install ?  Can i ssh to docker container ? Lets think..
  6. 6. Every process must be able to access only the information and resources that are necessary for its legitimate purpose - Diogo Mónica, Docker  Linux namespaces (isolated view of system.)  Cgroups (limit and isolate the resource usage.)  Linux Security Modules (Apparmor,SELINUX)  Capabilities  Per-container ulimit  User-namespaces: root inside is not root outside  Seccomp: Individual syscall filtering (like chrome sandbox) Enter Least Privilege
  7. 7. Linux Namespaces
  8. 8. Linux Namespaces
  9. 9. Cgroups, ulimit & User Namespaces  Docker root is not real root. (User Namespaces)  Docker ulimit  With cgroups, you can control on the resource usage of container docker run --lxc-conf=lxc.cgroup.cpuset.cpus = 0,1 ..
  10. 10.  Root has certain capabilities, but we don’t want our container to have all those capabilities  Each container can have some of the capabilities of root, but not all.  Mounting operations  Access to raw sockets (prevent opening privileged ports, spoofing)  Some file system operations (mkdev, chown, chattrs)  Loading kernel modules Capabilites
  11. 11.  man 7 capabilities  Docker by default drops some capabilities  sys_admin, sys_time, sys_nice,..... Capabilites docker run –cap-drop=CHOWN ... docker run –cap-add=MKNOD ...
  12. 12. Seccomp & Syscalls System Calls OS Utilities IP Tables Other User Programs Device Drivers NetFilter Other Kernel Components
  13. 13. Seccomp & Syscalls
  14. 14. Seccomp & Syscalls  You can block system calls from seccomp. Quite like sandboxing.  Supports syscall filtering by using BPF  SIGKILL signal to process, who made blocked syscall docker run –lxc-conf=common.seccomp ...
  15. 15. More...  Combine Docker with AppArmor/SELinux/TOMOYO Profiles  These profiles help you in deciding minimal privilege for each application.  Preventing permission escalation and unauthorized information disclosure (or worse).  Within the container configuration the related AppArmor profile can be defined with lxc.aa_profile. docker run –security-opt label:type:svirt_apche ...
  16. 16.  GRSEC and PaX  Use a hardened Linux kernel for host, with kernel patches.  User Mappings  Map user/group ids  lxc.id_map = u 0 1000000 65536  lxc.id_map = g 0 1000000 65536  Couple it with docker run –lxc-conf= More...
  17. 17. Can you really trust your images ? Docker Notary
  18. 18.  Trusted Cross Platform content distribution  Trusted Client – Server Interaction  Publisher signed content  Publisher Key validates integrity of content  Platform Agnostic to distribute any content Docker Notary
  19. 19. Docker Content Trust Publisher Registry User User User
  20. 20. Two keys are generated when publisher first pushes image.  Tagging Key  Exists for each new repository that publisher owns  Can be shared with collaborators easily.  Offline Key  Users see this key as official publisher’s key  Important in establishing trust.  Only needed when creating new repository or rotating existing repository Publisher’s View
  21. 21.  Once Images are signed, TUF maintains ensures  Integrity  & Freshness of Content  Notion of Timestamp Key  Needed to ensure freshness guarantees  Generated at remote server.  Docker maintains it for you Trust Update Framework
  22. 22. Lets Attack ?
  23. 23. Lets Attack ?
  24. 24. Lets Attack ?
  25. 25.  export DOCKER_CONTENT_TRUST=1 Docker Content Trust
  26. 26.  Security Script that checks for dozens of common best- practices around deploying Docker containers in produtions. DockerBench
  27. 27. Thanks
  28. 28. Questions ?? IRC: #docker #docker-security Google Group: Hyderabad Docker Users Join Docker Movement