Container Security Considerations: Security Best Practices and Common Threats
Understand container security challenges and learn about critical container security best practices, such as securing images, registries, etc.
Table of Contents
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 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?
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 ran as a non-root user which reduces the risk of malicious code or users from 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 allows for a better and a 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 physical or virtual machine host which can lead to an increased risk in 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 a some examples:
Categories | Threats |
Spoofing - Pretending to be something or someone you’re not | [S1] Certificates [S2] Arbitrary code execution [S3] Version 1.1 namespaces |
Tampering - Modifying something you’re not supposed to modify | [T1] Compromised Secrets [T2] Container Image Misconfiguration [T3] Linux vulnerabilities [T4] Registry vulnerabilities [T5] Application / Service Vulnerabilities [T6] Redis Vulnerabilities |
Repudiation - Claiming you didn’t do something regardless of whether you did or not | [R1] Root permissions |
Information Disclosure - Exposing information to people who are not authorized to see it | [I1] Namespaces [I2] Container in Public Cloud [I3] Network crosstalk |
Denial of Service - Attacks designed to prevent a system from providing service | [D1] Container Attack [D2] Orchestration Compromise [D3] Registry vulnerabilities |
Elevation of Privilege - A program or user with access to do things that they are not supposed to do | [E1] Container Breakout [E2] Root permissions |
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!
