Will Docker’s Lacklustre Security Lead to its Untimely Demise?

Since its launch in 2013, Docker has grown to become one of the mainstays in any developer’s tech stack. The option to deploy applications in containers not only isolates them from the server hardware, but also allows developers to create a consistent environment for deployment. However, this darling of developers has a security flaw that many overlook. 

Understanding the issue

We must look at Docker’s architecture to understand how the vulnerability can be executed. Docker is generally used instead of virtual machines as it reduces bloat and provides greater inter-compatibility. To ensure this, the software uses containers, which are standalone executables that contain everything required to run the application with no issues. 

Virtual machines, on the other hand, achieve resource assignment by creating discrete machines, each with their own OS, and manage them by using a hypervisor. In Docker, these containers are built on top of a container engine, which is an application running on the host operating system. Moreover, advancements in Linux like chroot and cgroups allowed containers to get closer to VMs in terms of resource partitioning. 

Docker took these features and packaged them into an easy-to-use service, adding on concepts like images, Dockerfiles, and the Docker CLI. It also enabled system admins to quickly deploy a large number of containers on the servers, and this is where the issue lies. The admin of a system can give users permissions to run Docker containers on a pre-deployed architecture. However, there is a very important step to not miss if the admin is deploying Docker containers on the server.

By default, Docker gives root-level privileges to the user. While most sysadmins ignore this warning, the Docker Wiki has a page dedicated to how this can be used as an attack vector for a server. 

Download our Mobile App

Root or superuser access in Linux-based machines is similar to administrator access in Windows, but more powerful. With root access, attackers can delete the entire file system, elevate normal users to the ones with superuser privileges, and install malicious software without notification or alerts. 

By accessing an unsecured Docker container, attackers can easily run a few lines of code after gaining access to run a privilege escalation exploit. This means that the malicious actor can elevate the non-privileged account to a superuser account, opening up a bunch of new attack vectors. ItsShash, a Reddit user, stated, “Docker is inherently insecure due to the way Docker Daemon runs as root. So much of the issues with Docker can be mitigated by switching to Podman or another rootless container alternative.”

This exploit is nothing new in the Docker community, but malicious actors are finding more exploits and holes in Docker’s systems using this as an attack vector. In 2020, reports emerged that Docker was a prime target for cybercriminals, as looking for misconfigured systems with exposed admin access was an easy way to get into a secure environment. There was also a trend of malware being created specifically for Docker and Kubernetes systems. 

Running a container ecosystem at scale also requires sysadmins to follow a long list of Docker best practices to avoid unauthorised access. However, it seems that Docker’s security is far from being the last nail in its coffin, as the company is currently digging its own grave. 

Why Docker is dying a slow death

Docker’s slow demise can be traced back to the launch of Docker Swarm, an enterprise-focused container orchestration platform. Swarm allowed admins to deploy a large number of Docker containers simultaneously, but was locked behind a paywall. Kubernetes, on the other hand, offered all the features of Swarm and more for free, effectively beating Docker at its own game. 

What’s more, reports later emerged that Docker turned down the option to take a fledgling Kubernetes under its wing in favour of developing Swarm. Jérôme Petazzoni, one of Docker’s first and longest serving employees, stated in an interview, “The biggest mistake was to miss Kubernetes. We were in that collective thought bubble where internally we thought Kubernetes was way too complicated and Swarm would be much more successful. It was our collective failure to not realise that.”

While Docker sought to get ahead of the industry trend by creating the Open Container Initiative (OCI) in 2015, this turned out to be a dagger in their back. While creating open standards is important for the future of any technology, it opened the door for Docker’s competitors to step in when its industry position started to erode. 

Erode it did, with Docker’s acquisition by Mirantis in 2019. This was followed up by a spate of hasty monetisation changes, rate limiting, and  changes in licensing terms with tech giants Docker had previously set agreements with. This then led to an exodus from the Docker ecosystem, with Kubernetes and RHEL cutting off support for dockershim. 

Developers slowly started to move to other alternatives like Podman, which ironically relies on the OCI standard set by Docker. Northeastpaw, a Reddit user, sums it up perfectly, “Docker the company is in a hard spot. They will die eventually because they weren’t ever able to acquire a consistent revenue stream and there’s not much they have now that can provide them that.”

While Docker might not be going anywhere for the near future, it is clear that the IT landscape ten years down the line will not include this software as part of the tech stack. Maybe some other OCI-based containerisation software will take the market leader position, but with Docker’s current trajectory, it might be consigned to the software graveyard.