Docker #1

By 01/16/2019 January 21st, 2019 No Comments

Every new solution which might even remotely seems to want to stay in our production infrastructure, be it a Datacenter or a Cloud triggers a defensive feeling of distaste and despise. It’s a healthy and well-developed mechanism. Some solutions stay in the infrastructure and it, as an organism, rejects them by itself like a failed organ transplant. Some, due to a number of reasons adjust and begin to fit. They pass the stability test, usability test and at the very end undergo scrutiny in terms of safety and security. This limits the number of solutions that remain with the infrastructure even further but those that survive… well they become ‘our solutions’, the right solutions the full-proof solutions. What we should keep in mind is that we need to give them all a chance and get to know their fortes and their weaknesses rather than to trust and repeat all the babble that fills the internet.

We’ve all heard that Docker is pure evil, it’s bad for you, it’s dangerous, unstable and, if you think about it, it’s essentially a Pandora’s Box… but wasn’t it the same with Virtualization or the Overlay Networks? I think it’s worth having a look at Docker’s current state of affairs due to these very examples from history. So, let’s open our minds and allow ourselves a little affair with Docker and then put it through the tests. But let’s not waste time on the philosophical aspects of security as it’ll lead us astray. Let’s assume we’re touching the peak of the iceberg in the context of container security in the configurational and operational layers.

Let’s start by checking how is Docker constructed and where does the little devil live in our Infrastructure.

Assume that Host is a physical server or a virtual machine – it really doesn’t matter as we’re focusing on the operational system in context of containerization and we call it ‘Hardware Land’. There we can find the ‘Docker Engine’ or ‘Docker Daemon’ – the infernal engine that allows us to run ‘Docker Images’ which contain apps which, when run, are called ‘Containers’. Containers are built of layers; binaries and libraries which are essential to running the App as well as the App itself which is also a layer. In our virtual world, ‘Docker Engine’ is a kind of a service run on ‘Hardware Land’ and a hypervisor of the ‘Docker Image’. The files with images of the virtual machines are the containers. As this might be a bit confusing, let’s leave it for a moment and in the meantime, let’s set up a small containerization environment. I would suggest a virtual machine and the below prompts can be run on Ubuntu, but you can easily map them for any of the Linux family members:

apt-get remove docker docker-engine
apt-get install apt-transport-https ca-certificates curl software-properties-common
curl -fsSL | sudo apt-key add –
apt-key fingerprint 0EBFCD88
add-apt-repository „deb [arch=amd64] $(lsb_release -cs) stable”
sudo apt-get install docker-ce

Using the above prompts, we delete any possible versions of Docker, we add missing packages to add a necessary key for Ubuntu’s repos. Next dash to install ‘Docker Engine’ and this is how we set up our first container:

docker pull nginx
docker run -d -P -p 8080:80 nginx
docker container list
curl http://localhost:8080
docker exec -it [id] bash
touch /home/aaa

Using the above, we downloaded Nginx container from Docker Hub, a public library containing ‘Docker Images’. Then we set it up in the daemon mode (-d) aka. the background which allowed us to remain in the console of the OS of our ‘Hardware Land’ and map port 80 of the container to 8080. After that we displayed a list of running containers where we were able to see the ID of our Nginx, we checked that it’s working through localhost and 8080 port, we moved to the console using the ID of the container and created a file within.

This is the general outline of how it works and how it looks. What’s next? A few possibilities of where we might get attacked from– how to break, bite, chew and spit out our Docker Infrastructure. Stay tuned.