{"id":1060,"date":"2016-08-06T22:20:32","date_gmt":"2016-08-06T20:20:32","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=1060"},"modified":"2023-08-06T21:54:21","modified_gmt":"2023-08-06T19:54:21","slug":"exploring-docker-security-part-1-the-whales-anatomy","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2016\/08\/06\/exploring-docker-security-part-1-the-whales-anatomy\/","title":{"rendered":"Exploring Docker Security – Part 1: The whale’s anatomy"},"content":{"rendered":"
https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/08\/ballena-de-alas-largas-240873.jpg<\/figcaption><\/figure>\n

When it comes to Docker, most of us immediately start thinking of current trends like Microservices, DevOps, fast deployment, or scalability. Without a doubt, Docker seems to hit the road towards establishing itself as the de-facto standard for lightweight application containers, shipping not only with lots of features and tools, but also great usability. However, another important topic is neglected very often: Security. Considering the rapid growth of potential threats for IT systems, security belongs to the crucial aspects that might decide about Docker (and generally containers) being widely and long-term adopted by software industry.
\nTherefore, this series of blog posts is about giving you an overview of the state of the art as far as container security (especially Docker) is concerned. But talking about that does not make so much sense without having a basic understanding of container technology in general. This is what I want to cover in this first part.
\nYou may guessed right: Altogether, this will be some kind of longer read. So grab a coffee, sit down and let me take you on a whale ride through the universe of (Docker) containers.<\/p>\n

<\/p>\n

<\/h3>\n
\n

In medias res<\/strong><\/h3>\n

The approach I chose is about confronting you with a demo before I start telling you about anything related to Docker or containers. Don’t hesitate to perform the following commands on your own machine if you’ve Docker already installed. If not, here’s<\/a> a detailed guide on how to get it up and running on Ubuntu Linux. Guides for other platforms are also provided. In order to check if everything is working fine, type the following command and hit Enter:<\/em><\/p>\n

$ docker -v \nDocker version 1.11.2, build b9f10c9<\/pre>\n
Got it? Ok, then we can straight move on and directly launch a first Docker container. For now, don’t worry about having no idea of what you’re doing. Simply keep moving forward and everything will become clear sooner or later.<\/p>\n
$ docker run -i -t ubuntu:latest \/bin\/bash<\/pre>\n
What you should see now is a prompt like the one shown in the following listing. Type ls <\/code>and see what happens:<\/p>\n
root@9d4e8c9d2af1:\/# ls\nbin dev home lib64 mnt proc run srv tmp var \nboot etc lib media opt root sbin sys usr<\/pre>\n
So far, so good. I’ll bet you, there’re many questions which came up while you were following these instructions until now.  Taking the risk to get you even more confused, let me shortly answer some of these:<\/p>\n
Q: “In Listing 2, you used a quite complex command in order to run a Docker container. What exactly do these commands and options mean?”<\/span><\/p>\n
A: “In a nutshell, we told Docker to create a container on top of an Ubuntu user space (ubuntu:latest<\/strong>),  attach a terminal (-t<\/strong>) , open up an input stream which consumes our keyboard input (-i<\/strong>) and finally start bash in a new process (\/bin\/bash<\/strong>)<\/em>. As a result, you got that prompt after container startup was finished. We’ll soon talk about what exactly is going on under the hood.”<\/em><\/p>\n
Q: “As soon as I typed ls<\/code> <\/span> on that prompt, what I saw was the structure of an ordinary Linux file system (Listing 3). So we actually started a VM with docker run<\/code> <\/span>, didn’t we<\/span>?”<\/span><\/em><\/p>\n
A: “No, you launched a container instead of a virtual machine. Creating a new virtual machine also means booting a complete and independent OS kernel. But this is not what has happened here. You rather spawned a new process<\/strong> on your host system running Docker. As for the file system, you’re right: Our container indeed operates on his own one. We’ll cover this in the next section.”<\/em><\/p>\n
Q: “The container prompt we saw in Listing 3 looks kind of weird and unfamiliar. What’s behind that?”<\/span><\/p>\n
A: “The numbers and characters after the @ <\/strong>tells us about the container ID. Every Docker container is assigned a distinct identifier. Don’t care about the root <\/strong>for now, we’ll come back to this later. However, I can forestall that this is indeed the current user attached to this container session.”<\/em><\/p>\n
Q: “Maybe I should have asked this right at the beginning: What exactly can I do with containers and why should I ever use them?”<\/span><\/p>\n
A: “The point of containers is that they allow you to run applications, web servers, databases etc. in a lightweight, isolated environment provided by a process instead of a virtual machine. You certainly noticed that starting a Docker container is a matter of seconds. Have you ever tried that with a virtual machine? Another aspect is storage. The memory consumption of a single container process is within the range of a few megabytes, whereas a VM needs several gigabytes. So containers are not only faster, but also save lots of resources. “<\/em><\/p>\n
Before becoming a little more precise about what I chucked at you so far, let me close that first introduction with a short  and succint definition of what a container is. I will refer to this below from time to time:<\/p>\n
 <\/p>\n
“A container can be considered a special kind of isolated environment for at least one single process. Although all containers running on the same host share the available physical resources as well as the kernel services of the host OS, they’re fooled to exist exclusively as a standalone system and therefore are not even aware of other processes outside their ‘world’ or being virtualized at all. Their greatest advantage over conventional virtual machines lies in their ability to be multiplexed over a single OS kernel, whereas a classical VM usually boots its own one.”<\/em><\/p>\n
-M<\/em>e<\/p><\/blockquote>\n
\n
Container file systems<\/h2>\n
We’ve already seen that a Docker container seems to have its own Linux file system. Look around in your container from above  a little bit and you’ll soon be convinced that it really is an independent file system rather than the one of your underlying OS, no matter you’re running your Docker host in a virtualized environment or directly on hardware. However, didn’t we keep hold of a container being merely a process and not a complete OS? Why should a single process even have its own file system?
\nAccording to the definition we established above, what containers want to achieve is providing an isolated environment for its inherent processes. Amongst others, what this means is that all the services running in a container may not have any dependencies on the Docker host. This is exaclty what a dedicated filesystem per container gives us. It enables us to install the software and run the services we want, without having to worry about potential conflicts when it comes to other applications as well as their dependencies.<\/p>\n
Working on a container’s filesystem<\/h4>\n
In order to examine how this works, we’ll install and setup an Apache web server with just a few steps:<\/p>\n
# Running a container with port 80 exposed (syntax is: -p $HOST_PORT:$CONTAINER_PORT)\n$ docker run -i -t -p 80:80 ubuntu:latest \/bin\/bash\n\n# Update mirrors and install Apache (inside the container)\nroot@123b456c:\/# apt-get update && apt-get install apache2\n\n# Start Apache server (inside the container)\nroot@123b456c:\/# service apache2 start<\/pre>\n
Mind the usage of the -p<\/code> option with the first command in Listing 4. In order to expose any services hosted by a container, Docker requires the according container port to be mapped on a free port of the Docker host. In this case, we took port 80 of the container (where Apache is available on) and bound it to the same port on the host. As long as a free host port is elected, the choice of which one to use is completely up to you. After container startup, open up your favorite browser and either type http:\/\/localhost<\/strong> or http:\/\/{VM IP}<\/strong> if you’re working on a virtualized Docker host. If Apache welcomes you by saying “It works”<\/em> (see screenshot), well … then it everything works.<\/p>\n
\"apache_docker\"<\/a>
Figure 1: Greetings from the Apache server running inside our Docker container<\/strong><\/figcaption><\/figure>\n
Container filesystem internals<\/h4>\n
At this point, we’ve understood that each Docker container comes with its own filesystem, where all kinds of software can be installed without interferfing with other containers or the Docker host itself. However, it must be considered that everything that’s installed into a container makes it increase in size. Let’s take the opportunity and check the size of the Ubuntu user space we’ve used so far:<\/p>\n
# List all the available Docker images (details will be provided later)\n$ docker images\n\n# The size of our Ubuntu image is shown in the last column (the rest can be ignored for now)\nREPOSITORY      TAG         IMAGE ID        CREATED         SIZE\nubuntu          latest      321def123       11 weeks ago    120.8 MB<\/pre>\n
The docker images<\/code> command returns a list of every Docker image <\/em>currently available on our Docker host. Docker image? Well, speaking honestly, a Docker image de facto is nothing but another designation for a container filesystem established by Docker itself. Subsequently, when diving deeper into container filesystems, I will preferably refer to them as images.<\/em> Coming back to the current subject, our Ubuntu image has a magnitude of 120.8 MB.
\nNow, imagine what might happen if you keep on installing more and more software on top of that filesystem. Eventually, it would be several gigabyte in size. Thinking of a bunch of different Docker images for various intended uses existing on the same hard drive, a container system’s advantage over a VM in terms of storage would diminish more and more. In order to avoid such an expansion and maintain its efficiency, Docker works as follows:<\/p>\n