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?

• LXC (Linux Containers)

• Docker

• Podman

• CoreOS AppC

• Solaris Zones

• FreeBSD Jails

• AIX Workload Partitions

• 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?

A visual difference between VMs and Containers

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?

A visual representation of defense-in-depth

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!