Operating Docker Securely - BSM

Transcript

1. Operating Docker Securely Jen  Andre
2. about me @fun_cuddles  /  jenpire.com  /   organizer  @BostonGoLang   EIR  @Accomplice   co-­‐founder  @threatstack,    formerly   researcher  @Mandiant,  engineering  /   security  analyst  @Symantce    
3. Come  to  our  launch  happy  hour!     Sign  up  at  hacksecure.org/events  
4. what is ?
5. “Docker  containers  wrap  up  a  piece  of   soMware  in  a  complete  filesystem  that   contains  everything  it  needs  to  run:  code,   runPme,  system  tools,  system  libraries  –   anything  you  can  install  on  a  server.  This   guarantees  that  it  will  always  run  the  same,   regardless  of  the  environment  it  is  running  in.”
6. docker is ‘virtualization’ • “process”  vs  “system”  virtualizaPon   • the  kernel  is  your  hypervisor   • the  isolaPon  properPes  are  not  the  same. ^lightweight
7. how it works
8. benefits and features • speed  of  provisioning     • startup  1me  in  seconds,  not  minutes   • “build  once,  deploy  anywhere”   • speedy  builds  and  deployments   • image  layering     • resolves  tension  between  “build”  vs.  “bake”  to  facilitate   immutable  infrastructure   • image  repository  facilitates  reuse   • DockerHub
9. It’s real and it’s here.
10. is docker secure?
11. this is the wrong question.
12. managing misinformation VS http://iamondemand.com/blog/5-key-benefits-of-docker-ci-version-control-portability-isolation-and-security/ http://www.securityweek.com/disrupting-disruptor-security-docker-containers
13. 1.    How  does  proposed  Docker  usage  change  my  threat   model?   2.    How  do  I  ensure  I  can  trust  the  code  running  in  my   containers?   3.  How  do  I  know  if  I’ve  configured  my  Docker  host  +   containers  in  a  way  that  minimizes  my  risk?   4.  How  do  containers  change  my  security  pracPces,  e.g.   monitoring? questions for the security professional
14. but also consider the  consistency  of  applicaPon  environments  in  Docker   containers  provides  for  interesPng  opportuni1es  for   new  automaPon  around  security  hardening,  audiPng,   and  tesPng.
15. issues with trust docker  images  are  binaries  (opaque)   who  am  I  trusPng?   who  is  updaPng  these  things  when  there  is  a  criPcal   security  flaw?  
16. The problem of patch management is a real thing. http://www.banyanops.com/blog/analyzing-docker-hub/
17. confusing advice http://serverfault.com/questions/611082/how-to-handle-security-updates-within-docker-containers
18. always be updating! • Do  perform  security  upgrades  (debian  example   below)   • sudo  docker  exec  -­‐it  <container>  apt-­‐get  update     • sudo  docker  exec  -­‐it  <container>  apt-­‐get  upgrade   -­‐s  |  grep  -­‐i  security  #  dry  run   • sudo  docker  exec  -­‐it  <container>  apt-­‐get  upgrade   #  commit  changes  when  done  
19. who are you trusting?
20. what  if  someone   replaced  libc  with  a   backdoored  version?
21. community   addressing trust automate  policy  audiPng  +   enforcement for  a  given  container,  tell  me  who/what   I  am  trusPng build  from  a  trusted  base  image be  aware  of  who  you  are  trusPng don’t  overrely  on  Docker  hub tooling  to  apply  and     validate  security  updates
22. more advice • “The  best  opPon  is  to  block  index.docker.io  locally,  and   download  and  verify  images  manually  before  imporPng   them  into  Docker  using  docker  load.”   • hcps:/ /Ptanous.com/posts/docker-­‐insecurity#fn:4   • Use  a  private  docker  registry   • hcps:/ /www.digitalocean.com/community/tutorials/how-­‐to-­‐set-­‐up-­‐a-­‐private-­‐docker-­‐registry-­‐ on-­‐ubuntu-­‐14-­‐04  ,  hcps:/ /quay.io         • Use  RedHat  cerPfied  containers   •  hcp:/ /www.redhat.com/en/about/press-­‐releases/red-­‐hat-­‐announces-­‐cerPficaPon-­‐for-­‐ containerized-­‐applicaPons-­‐extends-­‐customer-­‐confidence-­‐and-­‐trust-­‐to-­‐the-­‐cloud  
23. opportunities • trust,  but  verify:  build  an  binary  audiPng  tool  for  Docker   images!   • e.g.,  scan  images,  validate  installed  libraries  and  binaries    do   not  have  criPcal  security  issues  and  align  with  signed  package   manifests.   • hcps:/ /github.com/banyanops/collector    +`cruM’  but  for  containers?   • hcps:/ /github.com/OpenSCAP/container-­‐compliance  -­‐  RHEL  only   • contribute  to  the  packaging/distribuPon  trust  conversaPon!   • hcps:/ /github.com/docker/distribuPon/pull/179   • references:  hcp:/ /theupdateframework.com/  
24. best practices, hardening, & secure configurations ]
25. the good! Docker  released  a   comprehensive   security  benchmark. hcps:/ /blog.docker.com/2015/05/understanding-­‐docker-­‐security-­‐and-­‐best-­‐pracPces/
26. the bad …it’s  118  pages  of  material!
27. the good!: can we automate these checks? dockerbench.com   github.com/dockersecuritytools/bacen  <-­‐  ping  me  or  @jerbia    at   github  to  contribute!
28. serverspec example
29. the problem of isolation
30. container hardening: the good there’s actually a lot of knobs to turn!
31. toggling capabilities • “give  root  without  all  of  root”   • use  flags  on  Docker  command  line:  —cap-­‐add,  — cap-­‐drop
32. cgroups • control  resource  alloca1on  (e.g.  memory,  cpus)   • prevent  one  container  from  sucking  all  of  the   resources  (DoS)  another  container  on  the  same  host   •  $ docker run -it --rm -m 128m fedora bash • hcps:/ /goldmann.pl/blog/2014/09/11/resource-­‐management-­‐in-­‐docker/
33. • user  namespaces  (soon!)  so  you  don’t  have  to  run   id=0  processes  as  root!   • seccomp  filtering  to  permit  or  block  individual   system  calls  (soon!)   • hcp:/ /opensource.com/business/15/3/docker-­‐security-­‐future coming soon
34. AppArmor  +  SELinux • SELinux  /  AppArmor  policies  (—security-­‐opt)
35. using apparmor with 1. Create  the  custom  profile:  vim  my_container_profile   2. Load  it  into  app  armor:  cat  my_container_profile  |   sudo  apparmor_parser  -­‐r   3. ` 4. Run  it  with  your  docker  container:  docker  run  — security-­‐opt=“apparmor:my_container_profile”   5. $$$  Profit?
36. • Docker’s  default  capabiliPes  are   set  by  app  armor!  (and  turned   off  when  you  docker  run  — privileged=true)     • be  careful:  when  you  supply   your  own  apparmor  profile,   your  are  essenPally  resetng   the  capabiliPes.   • copy  or  inherit  these  when  you  create  a   new  profile  for  your  containers.       this looks familiar…
37. the bad there’s a lot of knobs to turn :(
38. we can do better.
40. • IF  in  the  future…   • DockerHub  registry  becomes  your  go-­‐to  trusted   distribuPon  source  for  applicaPons.…   •  Why  not     • Have  a  registry  for  apparmor  and  SELinux  profiles   geared  for  official  dockerized  app  containers?   • …Include  seccomp  filters  and  other  security  configs?   • Share  your  polices  &  reduce  the  burden  of  having  to   harden  your  own  apps/containers.
41. #  fetch  apparmor  security  profile  for  wordpress   image   docker  security-­‐profile  fetch  wordpress:latest       #  you  can  even  fetch  by  image  /  tag   docker  security-­‐profile  fetch   0cc6ffbf1a0cd78ab244c4b3b5cef13618bf4c8bcd229ec2673 1a951c33df72e     #  allow  users  to  submit/push  their  own  app  armor   profiles     docker  security-­‐profile  push  —-­‐profile=“apparmor:/ etc/apparmor/wordpress.profile”  jandre/ wordpress:custom
42. in conclusion • we  need  more  automaPon  around  security  audiPng,   hardening,  tesPng,  and  monitoring   • InnovaPon  here  should  come  not  just  from  the   Docker  folks.   • The  consistency  of  Docker  containers  enables  us  to   be  innovaPve  in  how  we  automate  the  above  ^^  
43. is this interesting to you? • contact  me!  jandre@gmail.com   • follow  @securedocker  for  Docker  security  news   • Visit  me  at  hacksecure.org