Docker Inc have worked with the Center for Internet Security (CIS) to produce a benchmark document [pdf] containing numerous recommendations for the security of Docker deployments. The benchmark was announced in a blog post ‘Understanding Docker Security and Best Practices’ by Diogo Mónica who was recently hired along with Nathan McCauley to lead the Docker Security team. The team have also released an ‘Introduction to Container Security’ [pdf] white paper.
The benchmark document covers configuration of the host running Docker, configuration of Docker itself, and configuration of containers running under the management of Docker. It addresses Docker 1.6.0, which is the latest version at the time of writing, and is based on Red Hat Enterprise Linux (RHEL) version 7 or Debian version 8 as the host operating system (OS). A checkbox table for each recommendation is in an appendix to the benchmark.
Recommendations are split into two levels, with level 1 associated with measures that are, “practical and prudent, provide a clear security benefit and don’t inhibit the utility of the technology beyond acceptable means”. Level 2 recommendations are more intrusive, and are described as, “intended for environments or use cases where security is paramount, acts as defense in depth measure or may negatively inhibit the utility or performance of the technology”. Level 1 recommendations apply to both the host OS and Docker, whilst the 3 level 2 recommendations, that relate to mandatory access control (MAC) and endpoint protection platform (EPP), apply only to Docker.
Many of the recommendations come with a script fragment in their audit section that can be used to determine whether configuration is in the desired state, which holds out the promise that much of the benchmark might be assembled into a script that could check (and reconfigure) a host for compliance. Remediation steps are also described with script fragments where appropriate, though these are less useful as in most cases it will be necessary to edit init configuration. As all of the major Linux distributions have now switched to systemd as their default init system, CIS might have chosen to show the appropriate configuration steps for that, but that would have risked confusing many users still running Docker on older distributions.
Whilst some of the recommendations are quite general, such as “do not use development tools in production”, the majority of the recommendations are very specific and actionable, such as “do not use aufs”. The benchmark can thus be used to profile a specific Docker environment and determine practical steps that can be taken to improve its security. Where multiple choices exist due to differences in the underlying host OS numerous references are given to external guidance documents authored by members of the Docker core team and others.
A number of items that might previously have been considered container best practices such as, “one container one process”, and, “do not run SSH within containers” feature in the benchmark as security recommendations. This will likely further undermine the usage pattern of containers as mini virtual machines by labelling it as a security problem.
There are some peculiarities in the benchmark that will hopefully be addressed in future versions. One is a reference to user namespace support in a future version of Docker, suggesting that it might come in 1.6 (even though the benchmark is about version 1.6). This might show that integration of user namespaces is proving to be more problematic than anticipated. The benchmark also recommends the use of nsenter even though its use has been largely displaced by the ‘exec’ command introduced in Docker 1.3.
The whitepaper that accompanied the launch of the benchmark shows that Docker Inc are trying to position containers as a way to improve security, but as with any new technology the company faces a tough time persuading customers with security concerns that they’ll be safe running in production. The release of the CIS benchmark provides those wanting to run Docker in production with a measurable means of evaluating their security posture, and that is likely to help ease any concerns. For developers who are embracing Docker to package applications, speed up continuous delivery pipelines and facilitate microservices architectures this should make the final steps to production somewhat easier to navigate.