Top 7 Docker security risks and best practices

To say that Docker containers are popular would be an understatement. Approximately 84 percent of enterprises were running at least 100 containers in production as of 2023. Some of these companies deploy many thousands of containers in enormous clusters. Without an effective Docker security strategy in place, organizations risk their containers becoming the weakest link in their overall security posture–and eventually, costly breaches. 

Continue reading for a look at Docker container security, including a deeper dive into the different types of security risks and challenges containers pose. We’ll cover why securing containers is such an important initiative, and best practices for keeping containerized workloads safe without compromising performance or reliability.

What is Docker container security?

Docker container security is the practice of securing workloads hosted in Docker containers. It extends to all stages of the container lifecycle, including:

• Securing Dockerfiles, which are the “blueprints” used to define and create container images. Problems such as configuration oversights or insecure software installation instructions inside Dockerfiles can introduce risk to containers.

• Protecting container images, or the binary code used to execute containers. If insecure code makes its way into container images— either through deliberate tampering with the images by attackers or the accidental inclusion of vulnerable software components–it could lead to costly breaches.

• Securing containers at runtime. Container runtime security requires protecting all facets of the runtime environment, from the servers that host containers, to the runtime software that executes them, and the processes running inside individual containers.

People often use the term “Docker” to refer to containers in general, not just the Docker platform. So the same general security principles and challenges apply to any type of modern container framework.

Top 7 security risks in Docker containers

Various risks can arise when developing, building, deploying, and running Docker containers. The following are among the most common.

CVEs in container images

A CVE (Common Vulnerabilities and Exposures) is an identifier assigned to publicly known security vulnerabilities, making it easier for security teams to track and catalog specific flaws across different codebases and tools. Code that contains CVEs can find its way into container images if developers include insecure packages, libraries, or other components when creating the image. Threat actors can then exploit these vulnerabilities to take control of containers that are deployed based on the images. For instance, if there were a CVE in your hosting website's image, an attacker could install a logger on your front page to start scraping usernames.

Malicious code in container images

If containers are not properly verified to be from a trusted source, they may contain malicious code or backdoors that allow attackers to inject code into the container itself once it runs. A real example of this is called “cryptojacking” where someone may introduce a cryptocurrency miner into your server if you include their image, stealing your computing capacity and racking up your energy bill.

Unrestricted privileged mode

Running a container with the–privileged flag grants it access to resources owned by the host system, significantly increasing the harm that could result from a successful attack. For instance, a compromised container running in privileged mode could modify files on the host system, access sensitive data, or even take over the host operating system. This is called “pivoting” in the world of computer security and is a potentially very powerful kind of attack. If your image running Jenkins had a CVE and was also running with the --privileged flag, an attacker could pivot to an image running your customer database and query, steal, or even delete all of their information. 

Weak or misconfigured networking

Exposing unnecessary ports or using default network configurations can make containers vulnerable to attacks that exploit vulnerabilities in network protocols. In addition, unrestricted inter-container communication may allow attackers to move laterally between containers, exacerbating the damage caused by the compromise of one container.

Unpatched container runtimes

Container runtimes are the software that executes containers based on a container image. Container runtimes like Docker Engine, containerd, and runc can have their own vulnerabilities separate from what's inside your containers. For example, CVE-2024-21626 was a bug in runc itself that allowed attackers to escape from any container (even if the containerized application was secure) and access the host system. 

Host operating system vulnerabilities

The operating system of the server or servers that host containers may also be subject to CVEs or misconfigurations that threat actors can leverage to compromise containers or run arbitrary code.

Insecure storage resources

Misconfigurations or poor practices when managing storage resources for containers to access can trigger security risks. For example, mounting a sensitive host directory (like /var/run/docker.sock) inside a container would expose the Docker daemon to the container, making it possible to compromise the entire system.

Likewise, mounting a directory that includes sensitive data (like personal files stored inside a user’s /home directory) would make that data accessible inside the container, potentially leading to data leaks.

Top 7 Docker container security best practices

To mitigate risks like those described above, teams responsible for developing and deploying Docker containers should adhere to the following best practices:

#1. Use zero-CVE container images

Developers typically use container images created and maintained by third-party open source projects. These images serve as the foundation for applications they want to run inside containers but often contain tens or hundreds of CVEs. Because vulnerabilities inside a base image will make the entire container vulnerable to attack, choosing secure container images is critical for protecting Docker containers from attack.

#2. Minimize the contents of containers

The less code that runs inside a container, the smaller its potential attack surface and the lower the risk of a breach. For this reason, it’s best practice to avoid libraries, packages, or other dependencies that aren’t strictly necessary. Choosing a minimalist image– meaning one with the bare minimum dependencies necessary to build and run an application– significantly reduces security risks.

#3. Use a minimalist host system

By a similar token, host systems are more secure when they have a minimal attack surface. In general, it’s optimal to choose a minimalist, memory-safe operating system when provisioning servers that will host containers. Minimalist systems include fewer processes and libraries than full-blown, general-purpose operating systems.

You can always install additional software if you need it, but it’s more secure to start small and build up than to include unnecessary code or tools by default in the host environment.

#4. Use kernel hardening on the host system

A kernel hardening framework can further improve host system security. These frameworks help detect and block malicious processes. They won’t always prevent breaches, but they provide a second line of defense that can make it harder for threat actors to exploit unpatched vulnerabilities.

#5. Update software automatically

All software involved in Docker container deployment—including software that runs inside containers and applications on the container host—should be updated regularly and automatically. Updates provide patches that address known CVEs, reducing the risk that attackers will find and exploit an attack vector, and providing new functionality.

Most operating systems provide automated update features that developers can enable to protect host servers. Inside containers, running startup commands like apt-get update; apt-get -y upgrade (for Debian and Ubuntu-based images) at runtime will update packages inside the container to the latest version.

#6. Run containers as unprivileged users

As noted above, running containers in privileged mode makes it easier for threat actors to launch and escalate attacks. To minimize this risk, execute containers using an unprivileged user with a command like:

docker run -u 1234 my-image

#7. Enforce resource quotas

Resource quotas restrict how much CPU, memory, and other resources a container can access. While these restrictions won’t prevent security breaches, they can help to mitigate their impact by preventing a compromised container from being able to use unlimited resources when executing malicious code.

Developers can enforce quotas in Docker using options like --cpu-quota at runtime. Orchestrators like Kubernetes also have built-in resource request and limit capabilities that can be configured when creating a container deployment.

Securing Docker containers with Chainguard

By providing minimal, zero-CVE container images that developers can use for deploying containerized applications, Chainguard addresses many of the most critical aspects of Docker container security. When you build your containers using CVE-free images that Chainguard has hardened and maintains, you don’t need to worry about insecure images undercutting your container supply chain security.

Contact us to learn more.