CIS Benchmark for Docker and Docker Bench for Security: why, how and when?

Question

I just learned about Docker Bench for Security and CIS Benchmark for Docker Community Edition.

Why, how and when am I supposed to use these tools?

Answer 1

Larger organizations are concerned that containers introduce more security risks than traditional VMs as there isn't any hypervisor segregation. Developers running arbitrary images, that run as root, that they don't bother to security patch, looks worse for security team's than automatically patched VMs controlled by ops teams without containers.

Misconfiguration of docker demon itself can also introduce security risks. It's fairly common for complex software to have security tuning tools and to run them as part of ”operational readiness checks” of the live environment before going live as a security audit. Then also run them on some periodic cycle or after any major upgrades of the software that is being audited. The tools you name will be very useful for that purpose.

Software vendors who build container orchestrators are actively working in removing any dependency on needing to run docker demon see cri-o.io. Security, footprint and fork time are areas that vendors are competing on. CoreOS was a big innovator in this space before they were acquired you can look at some of their architecture presentations to get a flavor of what containers at scale workout docker looks like.

From a devops perspective we should empower devs to run security tools all the time to fix issues early. In practice devs might be using Docker for Windows locally but the live env would be a container orchestrator possibly running rkt. In reality devs in large organizations are not going to security scan infrastructure they didn't create and dont have root on. Even at a startup not every dev can be familiar with all of the tooling and software running in production. An external security audit is a smart investment.

IMHO if your teaching containers from a developer perspective it's worth pointing out such tools. Certainly devs in my experience are woefully unaware that running containers they find on docker hub as root isn't the smartest way to be secure. I would only expect to see such tools to be covered in depth by courses teaching security analysts how to audit systems that use Docker.

Answer 2

Docker Bench is a scripted report of many of the CIS recommendations (at least those that can be scripted. Various organizations use the CIS recommendations as a starting point for their security policy, the goal is to have a recognized organization provide the best practices. This is useful when dealing with auditors in regulated environments since a company can often show what they've done towards the CIS recommendations to quickly get through most of the audit (the auditors will be familiar with the CIS recommendations).

That said, I personally feel the advice from CIS is a mixed bag when dealing with Docker. Some of the suggestions look like a copy and paste from advice given to security physical bare metal systems, rather than a sandboxed application. And some of the recommended practices, weird things like avoiding the use of ADD in a Dockerfile, have little security reasoning (anything you can include with an ADD of a tar you could include with a COPY of a full directory) and will flag just about every image you are running since ADD is used as the first step of nearly every base image. There's a list of other advice they give that has little to nothing to do with security and is just a recommended configuration setting that cannot be applied in all environments.

What's lacking with CIS recommendations for Docker is actually securing the applications running inside of the container. This gets out of scope since you can run anything in a container, and they often have other recommendations that cover this. However, I think it's important since many of the security exploits using containers have nothing to do with docker but rather running vulnerable applications in docker.

Because of this, my advice is to start with CIS but then adapt it for your own environment, remove the advice has little security benefit, and add in recommendations that can help secure the environment for your own use case.