Frankly Speaking - Container Security Risks
A guest post by Mike Privette
This is my first guest/cross-post written by Mike Privette, who is a security practitioner by day and runs an awesome website, Return on Security, by night. His website has a ton of unique resources for security professionals, such as investment insights, career advice, industry context, etc. You name it in security, he’s probably written something about it!
I encourage you to subscribe! Without further ado, here is his post about container security.
If you’re new here, please subscribe (or maybe buy a paid subscription)!
Containers Overview
Let's talk about containers.
What is a container?
A container is an operating system-level virtualization method for running multiple isolated Linux systems (containers) on a single control host which allows for multiple isolated user-space instances and resource management features
A container abstracts an application from the underlying operating system to enable faster development and easier deployment
What are the different types of container solutions?
Kubernetes (an orchestration platform technically, but I wanted to call this out for reference)
How long have containers been around?
Container technology has been around for over 10 years and has had a recent explosion due to the popularity of cloud computing
How are Virtual Machines and Containers different?
Virtual Machines
Run separate copies of the kernel
Communication with the host via virtual machine emulation
Containers
Share the same kernel
Communication with the host via standard system calls
Container Security Benefits
What are some of the security benefits of containers?
Application Isolation
Containers allow for processes inside the container to be run as a non-root user which reduces the risk of malicious code or users exploiting the application
Containers run as independent runtime environments with separate file systems and network stacks that are isolated from other containers and the host system
Containers allow applications to be segregated that would normally run on the same host and allows only pre-configured ports and files to be exchanged between containers
Reduced Attack Surface
A properly configured container will only contain the dependencies (libraries and additional software) required to run the application which can lead to a reduction of vulnerability attack surface
Containers are integrated with application dependencies which allow for a better and faster vulnerability patching process by minimizing the effort of validating compatibility between applications and patches
Container technology can be combined with underlying host hardening tools to add to defense in depth
Container Security Risks
What are some of the security risks of containers you should watch out for?
Added Complexity
The complexity and scalability of containers can lead to containers exposing more information than intended or allow for containers to be at different patch levels exposing risk
Not Complete System Isolation
The technology is not yet as isolated as virtual machine technology and shares the underlying kernel and OS with the host system. If there is a vulnerability at the system kernel level, it could provide a way into the containers running on the host.
There is no namespace isolation in containers, so a process that runs as root in a container will also run as root on the host system
Additional software and libraries can still be added to a container like a physical or virtual machine host which can lead to an increased risk of vulnerabilities
Potential for malicious code to break out of the container and affect the host system
Container Security Defense-in-Depth
How should you think about applying defense-in-depth practices to containers?
Container Threats Mapped to STRIDE
If you're not familiar with Threat Modeling, it can be best described as:
A structured representation of all the information that affects the security of an application. In essence, it is a view of the application and its environment through the lens of security
STRIDE is a popular threat modeling framework and here I'll share a non-exhaustive list of container threats mapped to this framework.
STRIDE evaluates the system detail design. It models the in-place system. By building data-flow diagrams (DFDs), STRIDE is used to identify system entities, events, and the boundaries of the system.
Here are some examples:
Wrapping Up
I hope you've enjoyed this point of view on container security challenges and learned something new.
This post isn't intended to be an exhaustive list of threats and best practices, but a general point of view and orientation.
Technology changes so fast, so I'm sure there's more that I didn't cover here. If you see something I'm missing (or just wrong about), let me know. I always enjoy learning more!
I thought it is possible to create namespaces where a container thinks it's running something as root but when in reality it's running as a different user if looked at from the host. There is some isolation that has been improved now when using docker/kubernetes. Am I misunderstood?