Container Hardening with Docker Bench for Security
[su_spoiler title=”Disclosure” icon=”plus-circle” anchor=”disclosure”]
This post is based on observations I made while attending Tech Field Day 12. I wasn’t compensated for writing this post, nor was I compensated for attending the event. My travel and incidentals to attend the event were covered by Gestalt IT. For more info, see our Disclosures page.
Security is front and center in today’s data center, and for good reason. Even a fairly small-scale breach can result in massive damage. As such, organizations need to be especially sensitive to security findings and new vulnerabilities. When virtualization was becoming mainstream, VM security was a common topic. IT Security professionals would debate, at length, the potential vulnerabilities of a virtualized environment. Perhaps the most infamous scenario is “VM escape.” This term is used to describe a situation where an attacker compromises a guest virtual machine and is able to “escape” the virtual machine’s process and access other host processes on the hypervisor – either the hypervisor itself or other virtual machines and the network.
Virtualization leaders put significant effort into making sure these sorts of security issues were handled and loudly dismissed VM escape as a real threat. And just when we were all starting to believe them, researchers at CrowdStrike demonstrated what we now know as CVE-2015-3456, the vulnerability dubbed “VENOM.” By abusing some vulnerable code in QEMU’s virtual floppy drive, attackers were potentially able to gain access to the host system and other virtual machines running on that host. Although I’m not familiar with any headline news stories resulting from failure to patch this vulnerability, it was a big deal and stirred up a lot of heated discussions.
How About Container Escape?
As containerization looms large, security professionals are directing some of the same questions at containers as they did at virtual machines. “If a container process is compromised, what kind of threat does that pose to the rest of the system? And how do we mitigate that risk?” In attempting to tighten up security, what you don’t know can hurt you. And you often don’t know what you don’t know.
Thankfully, in the historical example of virtualization, VMware has been faithfully releasing the vSphere Hardening Guide, which provides insight directly from VMware on how to tweak settings and change configuration to provide maximum security. This checklist affords security teams extra confidence when they put their stamp of approval on a VMware environment. Fortunately for containerization and those organizations testing or using it in production, Docker has partnered with the Center for Internet Security to provide a similar tool.
The CIS DOCKER 1.12.0 BENCHMARK V1.0.0 is a behemoth document (weighing in at close to 200 pages) that lays out, in explicit detail, the best practices for configuring Docker to have the strongest possible security posture. Assessing an environment against the benchmark can result in a score that helps present the relative security of the Docker configuration.
Docker Bench for Security
While there may be people out there who have the time and wherewithal to consume this enormous document and then manually confirm the configuration of every recommendation, most IT professionals don’t have that kind of time. We’re overloaded as it is, and place great value on tools that make this sort of compliance task simpler and more efficient. With that in mind, Docker offers the Docker Bench for Security script, which checks a Docker configuration against this published “hardening guide.”
The tool can be run a few different ways: Docker offers a pre-built container that can be simply run from the Docker host. Certain portions of this instantiation will be specific to the OS, so refer to the readme on the project’s Github page for more info.
[su_box title=”Run Bench container example”]docker run -it –net host –pid host –cap-add audit_control -v /var/lib:/var/lib -v /var/run/docker.sock:/var/run/docker.sock -v /usr/lib/systemd:/usr/lib/systemd -v /etc:/etc –label docker_bench_security docker/docker-bench-security[/su_box]
You can also instantiate the benchmarking container using Docker Compose:
[su_box title=”Run Bench container with Compose”]git clone https://github.com/docker/docker-bench-security.git cd docker-bench-security docker-compose run –rm docker-bench-security[/su_box]
And finally – and this is the way I tested this – you can just download the script and run it straight from your host.
[su_box title=”Run Bench script from Host”]git clone https://github.com/docker/docker-bench-security.git cd docker-bench-security sh docker-bench-security.sh[/su_box]
Once you’ve run the container or script, you will be presented with finding similar to the output pictured below!
What To Do with the Findings
Assuming you’re successful in firing off the script, you’ll see output similar to what is pictured below. The script results in Info, Warning, and Pass notes for each of the configuration recommendations, which are grouped into 5 sections:
- Host Configuration
- Docker Daemon Configuration
- Docker Daemon Configuration Files
- Container Images and Build Files
- Container Runtime
With the results of these findings, you can leverage the original benchmark document to remediate them. Which each recommendation (5.14, for example) there is a Remediation heading in the document which details the steps required to bring the configuration into compliance.
- Docker Bench requires Docker 1.10.0 or later in order to run.
- Also note that the default image and
FROM: alpinewhich doesn’t contain
auditctl, this will generate errors in section 1.8 to 1.18. Distribution specific Dockerfiles that fixes this issue are available in the distros directory.
- The distribution specific Dockerfiles may also help if the distribution you’re using haven’t yet shipped Docker version 1.10.0 or later.
- I linked to the 1.12 benchmark from CIS, but the Docker Bench for Security script is for 1.11 and doesn’t appear to have been updated for 1.12 yet.
- For further reading, check out the Docker Intro to Container Security whitepaper!