Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

An In-depth look at application containers

•Download as PPTX, PDF•
•
John Kinsella
John Kinsella

Slides for a talk I gave to the NIST cloud security working group on the state of container security. Due to this being a NIST talk, it's without branding or vendor mentions, where possible.

1 of 33
An In-Depth Look at Application Containers
Overview • A Brief History and Overview of Containers • Security Benefits(?) of Containers • Container Vulnerability Management • Responding to Container Attacks
Containers are not new, but…
Container Adoption Challenges
Source: ClusterHQ Container Adoption Challenges
Container (n): • Software-based isolation, for processes controlling… • Process grouping • Resource usage • What actions a process can take
cgroups
Grouping and constraints
What does a process do? • Auditing (read write audit events) • File access (read, write, create, delete) • Network access (bind, send, receive) • Process management (fork, kill) • Security (MAC) • Debug (tracing) • Administration (system config)
Capabilities • CAP_AUDIT_CONTROL • CAP_AUDIT_READ • CAP_AUDIT_WRITE • CAP_BLOCK_SUSPEND • CAP_CHOWN • CAP_DAC_OVERRIDE • CAP_DAC_READ_SEARCH • CAP_FOWNERCAP_FSETID • CAP_IPC_LOCK • CAP_IPC_OWNER • CAP_KILL • CAP_LEASE • CAP_LINUX_IMMUTABLE • CAP_MAC_ADMIN • CAP_MAC_OVERRIDE • CAP_MKNOD • CAP_NET_ADMIN • CAP_NET_BIND_SERVICE • CAP_NET_BROADCAST • CAP_NET_RAW • CAP_SETGID • CAP_SETFCAP • CAP_SETPCAP
Capabilities Worst to best: • Run with --privileged=true • Run with –cap-add ALL • Run with --cap-drop ALL --cap-add <only needed> • Run as non-root user, unprivileged Useful: capabilities section of documentation container runtimes
Security Benefits of Containers and Microservices • Smaller surface area* • Shorter lifespan* – shorter period when open to attack • More automated process – easier to recreate/redeploy* *(in theory)
Security Benefits of Containers and Microservices • Containerized apps lend themselves to ”12 factor” design 12factor.net
Security Disadvantages of Containers and Microservices • Relatively new technology • Lots of moving parts • Shorter lifespan – this makes investigations more difficult
Results of Twitter Survey
An In-depth look at application containers
Why Isolate? • Only as secure as your weakest link • What happens if other departments are running in your private cloud? • What happens if other customers are running in your bare metal CaaS?
Unikernels – Hardware Isolated Containers • Build custom VM images to boot bare OS to support single (usually) container
Brief Overview of Container Orchestration
Why Orchestration? • For “real” workloads: • How to launch 500 containers across 20 hosts? • Being aware of resources on each host • Getting storage and networking to right container on the right host • Distribution for speed, efficiency, cost, etc. • As part of a CI/CD process • How to do a rolling update of those 500 live containers to a new sw version?
Lots to Orchestrate Customer VM VM Image Management Networking Customer VM Local Storage NAS/SAN
Lots to Orchestrate Customer VM VM Image Management Networking Customer VM Local Storage NAS/SAN Containers Container Image mgmt Container networking Container storage Host Host Image Mgmt Host Networking Local Storage NAS/SAN
Image Security • Where did an image come from? • Is it an official image? • Is it the right version? • Has somebody modified it?
Host Security • Follow standard hardening processes but only firewall host, not it’s containers • A host itself shouldn’t be “exposed” – there should be no public attack surface. Administer via known private network • One nasty exposure – privileged containers.
Vulnerability Management in a Container World
Managing Security Exposure in Containers
Smaller Image, Less Vulnerabilities • Avoid ”From:$bloatedDistribution” and similar • Software can’t be vulnerable if it’s not installed. An amazingly large percentage of public container images are based on bloated (500mb+) full distributions.
Why? Least Privilege • We want the smallest image possible, when we load it across 100 hosts • The smaller the image, the less exposure for potential vulnerabilities • If the parent image has a vulnerability, everybody based on that parent has to re-spin their image
Seccomp We need to build a list of system calls called by the program… …that we want to succeed • Guess (preferably educated) • RTFM (thanks John!) • Capture behavior – maybe /usr/sbin/strace • Disassembly?
Plan For Container Attacks • Before going to production, think about how you’d investigate an attack • Containers are mostly ephemeral • Collect logs at a central location • Practice identifying and snapshotting problem containers • Don’t forget about data backup/recovery
Thanks – Let’s continue the conversation! @johnlkinsella Slides posted at http://www.slideshare.net/jlkinsel
Addendum • Classification and grouping of system calls http://seclab.cs.sunysb.edu/sekar/papers/syscallclassif.htm
Data Sources • Container Adoption Challenges: RightScale 2016 State of the Cloud • Layered container image: Ubuntu • Namespaces and cgroups images: IBM Data and some graphics provided by:

More Related Content

An In-depth look at application containers

  • 1. An In-Depth Look at Application Containers
  • 2. Overview • A Brief History and Overview of Containers • Security Benefits(?) of Containers • Container Vulnerability Management • Responding to Container Attacks
  • 3. Containers are not new, but…
  • 6. Container (n): • Software-based isolation, for processes controlling… • Process grouping • Resource usage • What actions a process can take
  • 9. What does a process do? • Auditing (read write audit events) • File access (read, write, create, delete) • Network access (bind, send, receive) • Process management (fork, kill) • Security (MAC) • Debug (tracing) • Administration (system config)
  • 10. Capabilities • CAP_AUDIT_CONTROL • CAP_AUDIT_READ • CAP_AUDIT_WRITE • CAP_BLOCK_SUSPEND • CAP_CHOWN • CAP_DAC_OVERRIDE • CAP_DAC_READ_SEARCH • CAP_FOWNERCAP_FSETID • CAP_IPC_LOCK • CAP_IPC_OWNER • CAP_KILL • CAP_LEASE • CAP_LINUX_IMMUTABLE • CAP_MAC_ADMIN • CAP_MAC_OVERRIDE • CAP_MKNOD • CAP_NET_ADMIN • CAP_NET_BIND_SERVICE • CAP_NET_BROADCAST • CAP_NET_RAW • CAP_SETGID • CAP_SETFCAP • CAP_SETPCAP
  • 11. Capabilities Worst to best: • Run with --privileged=true • Run with –cap-add ALL • Run with --cap-drop ALL --cap-add <only needed> • Run as non-root user, unprivileged Useful: capabilities section of documentation container runtimes
  • 12. Security Benefits of Containers and Microservices • Smaller surface area* • Shorter lifespan* – shorter period when open to attack • More automated process – easier to recreate/redeploy* *(in theory)
  • 13. Security Benefits of Containers and Microservices • Containerized apps lend themselves to ”12 factor” design 12factor.net
  • 14. Security Disadvantages of Containers and Microservices • Relatively new technology • Lots of moving parts • Shorter lifespan – this makes investigations more difficult
  • 17. Why Isolate? • Only as secure as your weakest link • What happens if other departments are running in your private cloud? • What happens if other customers are running in your bare metal CaaS?
  • 18. Unikernels – Hardware Isolated Containers • Build custom VM images to boot bare OS to support single (usually) container
  • 19. Brief Overview of Container Orchestration
  • 20. Why Orchestration? • For “real” workloads: • How to launch 500 containers across 20 hosts? • Being aware of resources on each host • Getting storage and networking to right container on the right host • Distribution for speed, efficiency, cost, etc. • As part of a CI/CD process • How to do a rolling update of those 500 live containers to a new sw version?
  • 21. Lots to Orchestrate Customer VM VM Image Management Networking Customer VM Local Storage NAS/SAN
  • 22. Lots to Orchestrate Customer VM VM Image Management Networking Customer VM Local Storage NAS/SAN Containers Container Image mgmt Container networking Container storage Host Host Image Mgmt Host Networking Local Storage NAS/SAN
  • 23. Image Security • Where did an image come from? • Is it an official image? • Is it the right version? • Has somebody modified it?
  • 24. Host Security • Follow standard hardening processes but only firewall host, not it’s containers • A host itself shouldn’t be “exposed” – there should be no public attack surface. Administer via known private network • One nasty exposure – privileged containers.
  • 25. Vulnerability Management in a Container World
  • 26. Managing Security Exposure in Containers
  • 27. Smaller Image, Less Vulnerabilities • Avoid ”From:$bloatedDistribution” and similar • Software can’t be vulnerable if it’s not installed. An amazingly large percentage of public container images are based on bloated (500mb+) full distributions.
  • 28. Why? Least Privilege • We want the smallest image possible, when we load it across 100 hosts • The smaller the image, the less exposure for potential vulnerabilities • If the parent image has a vulnerability, everybody based on that parent has to re-spin their image
  • 29. Seccomp We need to build a list of system calls called by the program… …that we want to succeed • Guess (preferably educated) • RTFM (thanks John!) • Capture behavior – maybe /usr/sbin/strace • Disassembly?
  • 30. Plan For Container Attacks • Before going to production, think about how you’d investigate an attack • Containers are mostly ephemeral • Collect logs at a central location • Practice identifying and snapshotting problem containers • Don’t forget about data backup/recovery
  • 31. Thanks – Let’s continue the conversation! @johnlkinsella Slides posted at http://www.slideshare.net/jlkinsel
  • 32. Addendum • Classification and grouping of system calls http://seclab.cs.sunysb.edu/sekar/papers/syscallclassif.htm
  • 33. Data Sources • Container Adoption Challenges: RightScale 2016 State of the Cloud • Layered container image: Ubuntu • Namespaces and cgroups images: IBM Data and some graphics provided by:

Editor's Notes

  1. Write-in: Provenance of containers
  2. We believe first compromised Docker-powered containers were running ElasticSearch