What Makes Containers Vulnerable?
Table of Contents
When looking for sensitive information and other valuable assets, attackers rarely access their target directly. Instead, they find vulnerabilities in other components and use them to weave through the system and escalate privileges where they can. Because containers add a layer of complexity to already large and complex applications, the attack surface is increased, giving threat actors more to work with. In this blog, we’ll go over the basic categories of container vulnerabilities and a quick list of things to address to keep attackers at bay.
What are the risks of containerization?
Containers make applications portable across different environments, simplify scaling, and allow developers to build, test, and deploy code quickly. There’s a lot of reward to be had, but containers are not without risk. Vulnerabilities can enter containerized applications through the application’s custom code or third-party dependencies, misconfigurations within the containers or host, through the base container images they’re built on, and through the host.
Application vulnerabilities
These are the vulnerabilities that you introduce through your code and the libraries you choose to use when building your containerized application either from the bottom up or on top of a base image. Application vulnerabilities can come from poor coding habits, such as leaving secrets like passwords and API keys in unprotected places, that you bring into your project. Application vulnerabilities are particularly troublesome in containers that have a lot of privileges.
Configuration vulnerabilities
Misconfigurations in containers or the host itself can leave an otherwise securely built container at the mercy of bad actors. Common misconfigurations allow containers to have privileges they shouldn’t, such as containers having write access when they should only be able to read, or running in root—a particularly pernicious problem since many services run containers as root by default.
Network vulnerabilities
Network vulnerabilities are also due to misconfigurations such as containers with ports exposed to the internet when they have no reason to be, exposed APIs, and containers configured to transmit data via HTTPS. Insecure container networks can allow traffic from one container to access all other containers, which can increase the damage an attacker can do if they can gain access to that container via other vulnerabilities.
Image vulnerabilities
The base (also called “parent”) images you build your containers on top of, even ones from trusted sources, can be vulnerable—and images from untrusted sources can be downright malicious. Base images can be made of many layers, all of which can easily become out of date and insecure. Malicious containers can look and function just like the trusted image they’re pretending to be while leaving a backdoor for attackers or injecting malware into your system.
Host vulnerabilities
A host vulnerability isn’t just a container vulnerability—it’s an all-of-your-containers vulnerability. Unlike with virtual machines (VMs), where every VM is isolated and accesses hardware directly via a hypervisor, containers have their own operating system (OS) but share a single host kernel. An attacker getting access to the host is bad news, as it can result in getting access to everything the host interacts with—that is, your whole system. An OS kernel can have vulnerabilities that can be exploited directly or vulnerabilities that can be targeted secondarily after a vulnerable container is exploited.
What makes containers more secure?
Although they undeniably increase the attack surface, containers do have some security advantages over other architectures like VMs. Containers may not run with isolated OS kernels, but they do run isolated from each other, which makes it easier to set up security for each container, keeping it protected if another container is exploited. Additionally, containers are easier to tear down and spin back up with updated components compared with a VM.
Most of the actions that keep containers secure are the same ones you’d take to keep any application secure:
- Apply the principle of least privilege (e.g. don’t let containers run as root).
- Use private registries.
- Keep the OS kernel, base images, and all libraries up to date.
- Monitor your containers and network.
- Use the smallest OS images you can get away with; less code = less to exploit.
- Use only base images and open source libraries from trusted sources.
- Employ secure coding practices.
- Scan your containers regularly to find any new vulnerabilities that may have cropped up
Secure containerized applications
About the author
