Can we really trust the official Docker images?

Sep 3, 2015

Yeap, this is another rant on the security practices of Docker users. Like we didn't have enough of those already.

I recently revamped the CI system we use at my workplace. I ended up using a combination of Phabricator, Jenkins, Docker and the Docker registry, but more on this on another blogpost. Since I made heavy use of Docker for all of the above, I started poking around the Dockerfiles that are used to create the 'official' Docker images for a bunch of projects. I didn't like what I saw.

I generally expect downloads for software to be either:

    a) signed using a trusted key
    b) if not signed, at least downloadble through `https`

if both of the above are missing, I refuse to download said software. It still surprises me that widely used software like nw.js offer none of the above.

It's sad to see the same thing happening with official Docker images.

This is an example of a good Dockerfile, a Debian repo (hosted by Mongo) is used to download MongoDB and the .debs are signed using a trusted key. Moreover, gosu is also verified using gpg. Note: this means the gosu developer must be trusted to not backdoor his software, otherwise you have to verify the download in some other way, like a sha256sum.

This and this are examples of what I consider insecure Dockerfiles. In the first example, archive.apache.org works with SSL just fine, why not use it by default? If the certificate of the site isn't valid -as it appears to be in the second link (SHA1 cert?)- just download the file from multiple sources, get its sha256sum and use it to verify the download.

All in all, while I believe that Docker is an amazing tool, I don't think a lot of its users are taking security seriously or into consideration at all. Personally, I wouldn't trust the official Docker images before taking a look at their respective Dockerfile and verifying that everything is to my taste.

Tags: rant security software