How to raise awareness about the security risk involved with running Docker?

Question

I'm in the process of preparing a Docker course for students with little to no familiarities with containers, the underlying OS mechanisms involved, and their implied limitations.

In many Docker tutorials, security concerns often go unmentioned. And it is easy to assume there are not much security issues involved by running containerized application on a general purpose system.

On my side, I would raise students awareness about these issues early as part of my course. It is not necessarily about teaching them how to mitigate these issues. But really about dismantle that misconception Docker is secure by default. Unfortunately, I could not afford spending to much curriculum time on these aspects.

So, I'm looking for tools and/or examples that could be easily run and understood by my students so they get an idea of the possible security implications of using Docker. What would you suggest?

---

For what it worth, I initially thought about:

• rooting a Docker host -- which seems a good example
• and running Docker Bench. But from that answer, Docker Bench is probably not the best tool for my particular needs.

Answer 1

You might also want to run a scan for security vulnerabilities of some sample base images so your students get an idea of how changing the base can affect how secure your image is. For example comparing an alpine image versus a full blown Ubuntu image (especially some of the older Ubuntu images).

Clair is a decent scanner that can be set up fairly easily in docker containers. It is also the scanner that GitLab use for container scanner if you use their CI / CD platform.

Answer 2

A tool that I think is rather under recognised is s2i. The basic idea is that you don’t put a Dockerfile into your source repo specifying the runtime to use you keep your app code bare (just code). The decision as to which security patched s2i image to compile and run the code with is a separate matter that is independent and can be centrally managed.

The way this is used in the OKD world is that a “BuildConfig” pulls your code from git to make an application image and is trigger by either a git webook or a docker registry push that updated the s2i image with a security patch.

In our case we have many node and php apps. To security patch either runtime we push the latest s2i image into our OKD docker registry and that causes all our application images to be recreated and redeployed.

Why I think that is of interest is that it basically says that what the code is, and how the code is run from a container security perspective, should not be conflated. They are two concerns that are not on the same cadence. A high impact vulnerability should be patched in the main test environment immediately and not be dependent on talking to several scrum teams about pushing a change to the Dockerfile in each team’s git repo.

When you have many apps or many small dev teams that separation to do “policy based security patching” of containers can be very useful. You can run s2i on your desktop or with container based SaaS ci tool such as circleci. It would be straightforward to run it in, say, Jenkins. That means you can have, say, dozens of micro service Jenkins deploy jobs triggered by git webook that run s2i and push the final image. You can then control the version of the s2i image you use in all the Jenkins jobs in one place. You can then script a security update that updates the s2i docker url to the latest security fix and triggers all Jenkins release jobs to run to apply the patched s2i to all microservices. No code or config needs to change in any git repo.

While I mention OKD by default it doesn’t let you run a container image as uid 0 (root). It uses a random uid and gid 0. This is for security in case the process gets out of its jail and tries to modify the host. Most public docker images just expect you run as root and file permission don’t let you run the app in the image as an arbitrary uid as docker —user ${rand_uid}:0. You have to bake an image that gives gid 0 the file permissions to run the app. The s2i images all work under these circumstances.

If you need apps in docker to lookup the use details in /etc/passwd when running as a random uid the you can fake that. Here is a script that runs git in docker as random uid where git wants to lookup the current in /etc/passwd so the script fakes it.

The lesson here IMHO is that while in theory docker gives perfect isolation in practice all code is subject to security flaws. In theory many small dev teams will update all Dockerfiles immediately or very frequently but in practice dev teams are focused on features not long term security patching. (I work with one microservies platform that currently has >200 git repos and dev teams on three continents so coordinating anything is a challenge.) So security should be “defence in depth” and take concrete steps to do centralised patching of container images, not run containers as root, and use a random uid that isn’t in the host /etc/passwd so cannot read or write outside of its jail.

Answer 3

In my experience with "raising awareness about security" (for technical-minded people) is simply to show them the problem in action.

Find out what concrete, practical problems actually exist, and just show them (by actually showing, or by having them find out for themselves).

All docker security problems I've come upon have been quite self-evident and kind of obvious in hindsight. Except for one issue way back (pre-1.0) where they originally had blacklist for kernel calls instead of whitelists, most other issues can readily be shown by configuration, or hello-world style images, or by sharp thinking ("do we really want to use the IAmNotEvil/SpecialUbuntuDistribution image from dockerhub instead of an official, and how do we know the official one is good?").

Oh, and for a complete discussion, don't forget to show them in which aspects Docker is more secure (or more easily secured) than a plain server...