Docker simplifies and accelerates your workflow and deployment. But due to this friendly behavior of Docker, we tend to overlook some of its limitations & vulnerabilities. In this post we'll be looking at Docker through a major aspect: Security.
For the past few posts in this series, we have been all about Docker. We've been telling you how easy it is to ship your applications in production.
To be honest for most people out there, Docker has become synonymous with containers. And why not? Docker has been widely adopted by the industry that it's now become the face for container technology.
But does this platform really have no flaws ?
Reality check. No one's perfect. Not even Docker! There are a few cases where Docker falls short. And we are about to tell you all about it in this post...
In Unpacking Containers & Docker Storage post, we described docker architecture and storing data in dockers using volumes & bind mounts in detail. We will be revisiting them to explain some of the flaws here in detail.
The Curious case of the Containers
Picture this. Naive Naomi is creating a docker image for her application using some open source "image X" as the base image. She saves her Dockerfile and builds the image. She then creates a container using the image and mounts a directory on her system as a bind mount.
Everything is going as expected, but then she notices something weird happening on her system. There's a ton of files being created and that too at an alarming rate! She digs around and sees that there are unknown files even in her system level directories. What's more seems like a lot of her files are corrupted and she's lost important data!
What's happening here? Let's find out.
Trace back Naomi's steps and you'll find the answer.
Of course! She'd created a docker container and used a bind mount. That's when things went awry!
Let's look at the possibilities...
Never have a Bad image!
When Naomi created her Docker image, she used an image X as her base image. She said that since image X had all the dependencies that she wanted for her application already installed. So she directly used the image since she could get away by adding minimal customization on the base image. And since the image was open source she could download and use it easily.
Little did she know that image X had a malicious script embedded in it.
As soon as the container started, this little piece of code went about its job of playing troublemaker by replicating itself and corrupting data on the host system.
When using a public image as base image for your application, always keep in mind to make sure that the image comes from a reliable source.
If you're exploring public images on registries like DockerHub, try using the official images . Watch out for stats like the large number of pulls and stars, regular updates. Or run a security scan on Docker Image (there a number of tools available for this).
The "Root" cause of the Issue
We know how the malicious script found its way to host system (through the image). But how did it get access to the host?
We know that Docker follows a client server architecture where the docker daemon (dockerd) is responsible to create and manage all the containers.
But to do that the daemon requires privileged access. When you say "privileged access", it means that dockerd runs with root access.
And, if you have root access of a system, you have the ultimate power! You can do anything on the system. Anything!
Change the system settings ? Yeah!
Access system level configurations files? Of course!
Install packages and libraries? Why not!
Crash the host by executing malicious code? Definitely!
Wait what....?
Yes, the bitter truth is that its possible. Because your docker daemon runs with root privileges, it makes it potentially possible for an attacker to gain root access of the host from within a container. A process can "escape" from the container onto the host and can wreak havoc. Not only that, it can affect the other containers too. An obvious hole in the security!
So in Naomi's case, how did the malicious script "escape" out from the container onto the host? ...Bind-Mount....... Of course!
And, how was the script able to infect the system level files and directories? It used dockerd's root access privileges to carryout this evil mission. Gotcha......!
And Now you know! Case closed!
The Daemon Demon
In all of this, there's one more thing you're probably missing out on. It's about the Docker daemon.
Basically, the docker daemon is a single process that runs on the host. Emphasis on single.
Whenever it has to create a container, it simply spawns a new child process and manages it throughout its lifetime. So you can say dockerd is the sole parent/caretaker/guardian for all the containers .
So what if, one day, the docker daemon is killed off ? Mayday! What about the containers? I mean, their only parent is killed. All these containers are now orphaned . And basically, they are floating about aimlessly in your system. Not a good situation!
In Linux terminology, a process is called "orphaned process" if the parent process is in the "killed state". We aren't telling you a tragic story, its actual technical definitions for Linux Systems!
Moral of the story; You simply cannot do without this dockerd chap. And you need to realise that. Since dockerd is a single process, its basically acting as a single point of failure.
Extra FYI : a Few More Limitations
Cryptojacking
Someone uses a malicious script to use your computer's computational resources and mine cryptocurrencies. So resources like CPU, memory and RAM are all used up. Aah! You can't use your computer anymore! That's cryptojacking.
Classic case of corrupt images through which an attacker gains root access on the host.
It's also possible if the docker container API endpoints are publicly accessible on the internet without passwords or security firewalls.
Static Dockerfiles
Images are immutable.
This means when an image is built, you cannot chage the contents later
This can give rise to vulnerabilities due to outdated packages or libraries within the image.
A Ray of Hope
Hey.. Don't lose hope. Docker isn't the only sole warrior out there. You got other options. There are secure alternatives where the "root access" issue is avoided. Want to find out? Head over to our next post!
Join the conversation