Dockerize Me – Cheat Sheet and Pyramid of Trust – Part 2

In part one of my ‘Dockerize Me’ story, I’ve been describing the reasons why I want to learn more about Docker and gave some first tips and tricks how to quickly install it with a few commands on a Debian based server. A first docker-compose project then demonstrated how to quickly spin-up a WordPress container that talks to a database in another container that stores the website’s configuration, the text of the blog articles, comments, etc. Before expanding on this example in part 3, here’s a cheat sheet of Docker and docker-compose commands that I use frequently. Also, I think it’s a good thing at this point to spend some thoughts on the pyramid of trust when getting images from Docker Hub.

So here’s my cheat-sheet of frequent Docker commands:

# Start containers, will restart when VM is rebooted
# Must be issued in the directory of the respective
# docker-compose project
docker-compose up -d

# Stop that are part of a docker-compose project.
# Containers are removed and will NOT restart when the 
# VM is rebooted
docker-compose down

# Get a list of all running containers and their NAMES
# -a also shows non-running containers, e.g. those that have exited…
docker ps -a

# Get a shell inside inside the container
docker container exec -it NAME_OF_CONTAINER bash

# Stop a container (if docker-compose is used, use docker-compose down instead)
docker stop NAME

# Get logs generated by the processes in side a container 
# (use --follow for continuous logging)
docker logs NAME_OF_CONTAINER
docker logs --follow NAME_OF_CONTAINER

# Memory, network, block io, pids status of ALL containers
docker stats

# Show all images currently on a server
docker images

# Location of named volumes
cd /var/lib/docker/volumes/

Whom Do I Have To Trust?

The second topic for today’s blog post is about whom I have to trust when I use Docker with images supplied from Docker Hub. The WordPress example described in part 1 uses two images that are downloaded from Docker Hub the first time docker-compose is invoked together with the docker-compose.yml file in the project directory:

mysql:5.7
wordpress:latest

So whom do I have to trust when I use these images? Obviously, I have to trust whoever maintains the Docker software and Docker Hub. According to hub.docker.com, that is Docker Inc., and this Wikipedia article lists the current owners. Trusting them means that I am confident that they keep the Docker software, which is  open source (see Wikipedia article on Docker), secure and that there are no secret back doors. And as far as Docker Hub is concerned, the company behind it has to ensure that the service is secure and nobody with malicious intent is able to modify images hosted there by other people and organizations.

The next level of trust one has to have is in those people and organizations that have built the mysql and WordPress images that are hosted on Docker-Hub. In both cases the images are maintained by the developers behind both products. I also have to trust those entities when I install their products on a server without Docker, so they are not adding an extra layer to my ‘traditional’ chain of trust when running open source software without Docker.

However, the WordPress image does not only contain the WordPress PHP files but is based on another image:

php:7.4-apache

The name of that image already says a lot about what it does: PHP is the scripting language that WordPress relies on and Apache is the web server. This image is maintained by the owners of PHP which I have to trust as well in the traditional software deployment model. And of course they only supply the PHP and the Apache web server part and base their image on a Debian operating system Docker image:

debian:buster-slim

And when you look at their Dockerfile, they are building it from SCRATCH. They therefore terminate the Docker chain of trust. But, of course, Debian in turn trusts a lot of open source software projects that they include in their Linux distribution.

Summary

I leave you to do this exercise for the mysql image on your own. In summary, Docker adds Docker Inc. as one additional entity I have to trust when running the WordPress installation described in the previous part. All other entities are also part of the chain of trust for a ‘traditional’ WordPress installation.