Security is the enterprise’s foremost concern on its way to production adoption of container technology. However, security is never a one-off deal, and in the context of the still nascent container technology that’s especially true.
Not only is the technology new, but the way it is used is evolving constantly. The features stream is very rapid. Security must therefore evolve side by side — tracking and learning the emerging threats, and the new features as they are being introduced.
In this context, it’s good to see the constant evolution of security standards and best practices.
In the previous release, Docker 1.10, security was almost the main theme. Now that Docker 1.11 was released, the CIS Docker 1.11.0 Benchmark released with it. This is an updated version of the initial CIS Docker 1.6.0 Benchmark. In case you’re not familiar with the Docker CIS benchmark, it is a document published by the Center for Internet Security that provides a comprehensive list of configuration best practices for hardening Linux hosts running Docker. It’s a very detailed document which, if followed, can significantly improve your security posture for running Docker, and it’s also a useful educational tool for getting intimate with various Docker features.
With the release of Docker 1.11, there’s been a significant change in the Docker architecture. This is the first release built on containerd conforming to the OCI standard, which breaks Docker into additional components. This and other new features are the trigger for the CIS benchmark update.
Notable CIS Benchmark Additions for Security
Following are what I think are the most significant additions to the CIS from a security perspective - the numbers are the actual article numbers in the document.
2.8 Enable user namespace support
This is an important feature introduced in Docker 1.10 which is still ‘in its infancy’. It enables running containers with UID 0 within a container, while being non-root on the host. While this feature is useful, there are still some challenges with its implementation:
- All container UIDs are mapped to the same UIDs on the host, so there’s no flexibility to change it and it may also create duplication in some scenarios.
- There are also some compatibility issues and certain features just don’t work.
2.11 User authorization plugin
Another feature that was introduced in Docker 1.10, the authorization plugin makes it possible to plug in the user authorization model, to implement role-based access control or other models.
This is potentially a useful feature, and certainly an improvement over Docker’s ‘all or nothing’ access model. It is not activated by default, something that I suspect will change over time.
Additionally, it’s an authorization plugin but not an authentication plugin, so you can’t use it to enforce user identity and authentication.
2.12 Configure centralized and remote logging
Docker now makes it possible to choose your own log driver and sync logs to a centralized log collector. For larger deployments, this is particularly important. It can help prevent log loss and open the door to centralized log analytics.
4.5 Enable Content Trust for Docker
This is one of the most fundamental aspects of a secure environment, as it gives you the confidence that an image’s origin is trusted and its content is safe.This feature is useful when using remote Docker registries - however, at this stage it’s somewhat limited, as only public Docker Hub is supported, but in the future it will become much more significant.
5.21 Do not disable default seccomp profile
The addition of default seccomp profile in Docker 1.10 was an important step forward. The seccomp filtering gives you give peace of mind as it reduces the attack surface of the Linux kernel by shutting down system calls that containers can access.
In some cases though, it can be challenging to use it as it may break container’s functionality. This guideline of not disabling the seccomp profile is spot on — admins should resist the temptation of just disabling it, and instead they should come up with a seccomp policy adapted to their environment.
5.25 Restrict container from acquiring additional privileges
The ability to prevent the acquisition of additional privileges, preventing the execution of SUID/GUID programs, was added in Docker 1.11. This will greatly reduce the threat surface. It prevents containers from running ‘exceptions’ to the ‘least privilege’ configuration.
This restriction is off by default — but the state of mind should be to turn it on by default, despite the burden that it places on the administrator to ensure that it doesn’t break functionality.
