The Crux with Leaks

Docker Hub is easy for users, and the docker command-line tool can directly tap into it. You can easily pick up prebuilt images for CMS, databases, or distributions and import them into your local infrastructure. But what guarantees do users have that the software running in the container is also free of vulnerabilities?

Threat Modeling

To start, you need to distinguish between threats; security experts refer to this as a threat model. In this case, there are three threat scenarios:

• The manufacturer embeds malicious code and offers infected images.
• Attackers tamper with the software en route from the manufacturer to the user.
• The manufacturer fails to eliminate known security vulnerabilities in its images.

Users need to select software vendors they trust for effective protection against the first case. Well-known and reputable companies would be reluctant to compromise their reputations, but a distant dubious download service should inspire some skepticism. Finding out who actually offers an image on the Docker Hub is important, because potentially anyone could upload it. Docker, Inc. [1] does not check uploads and typically leaves this responsibility to the user.

A good image usually contains a note on its build instructions – the docker file . Repository sites such as GitHub typically host these descriptions and let you download them. Thus, every user can reconstruct how an image was created. Of course, a review of this kind takes time, but it is worthwhile if the image in question will be playing a central role in your own infrastructure. Examples of this would be, for example, basic images for a Java application server or a preconfigured CMS in a container.

Official Images

The name of the image on Docker Hub consists of two components: The username and the actual name of the image, such as johndoe/mysql. If the first part is missing up to the forward slash, it is an official image. Official images play a very prominent role on Docker Hub, they are usually from the upstream projects themselves.

The official images help to ensure quality. Docker employees examine the related content and collaborate with upstream developers, security experts, and the community, according to company statements. Docker, Inc. defines some best practices for construction images with a view to security and other aspects [2]. This includes, for example, making sure that you only download the necessary Docker files via encrypted TLS or correctly validate Open PGP signatures.

Ultimately, Docker, Inc. accepts no liability whatsoever for the image. The projects themselves push their build instructions into a GitHub repository, from which Docker's service then assembles the images. It is very instructive to take a look at the help texts, scripts, and patches in the form of comments and pull requests hosted there. Currently, the figure is just over 100 official images, only a fraction compared to the tens of thousands of images to operator specs that Docker Hub offers.

But if you do not trust Docker Hub, official images or not, you need to look around for alternatives. Some providers of container platforms offer their own registries, Red Hat and Amazon, for example. Conceptually, this changes nothing in the threat model.

For production use in the enterprise, admins would do well to set up their own registries. This is something that you can do amazingly quickly, because there are also Docker images for this. The system administrator then only uploads in-house images or personally tested and verified images from other registries, to this registry. At the same time, you would exclusively allow the run-time environment access to this registry instead of the default.

Damaged in Transit

The second main threat can be quite easily contained with current Docker tools, because the communication between Docker and the client, the Docker host, and the registry is usually TLS encrypted and protected by SSL certificates without requiring too much work from the user.

The Docker Notary [3] project offers an approach for verifying end-to-end whether an image actually comes from the provider who the image claims created it. To describe this in a greatly simplified way, The Update Framework (TUF, [4]) on which the project is based computes a checksum on the manufacturer's side, and users then verify the image. The problem that this project faces is the immense complexity of some of the details, which makes it difficult to understand and thus difficult to use for many users.