Securing Docker with CIS Controls

Containers, along with orchestrators such as Kubernetes, have ushered in a new era of application development methodology, enabling microservices architectures as well as continuous development and delivery. Docker is by far the most dominant container runtime engine, with a 91% penetration according to the State of the Container and Kubernetes Security Report.

Containerization has many benefits and as a result has seen wide adoption. Gartner predicts that by 2023, 70% of organizations will be running three or more containerized applications in production. Containers, Kubernetes, and microservices application patterns are three of the leading drivers of enterprise IT innovation and digital transformation. Companies have embraced these technologies for their advantages in application development and deployment.

However, building apps using Docker containers also introduces new security challenges and risks. A single compromised Docker container can threaten all other containers as well as the underlying host, underscoring the importance of securing Docker.

Securing Docker can be loosely categorized into two areas:

• Securing and hardening the host so that a container breach does not also lead to host breach
• Securing and hardening Docker containers during the build and deploy phases and protecting your Docker containers during runtime.

To assist system and application administrators, security specialists, auditors, help desk, and platform deployment personnel who plan to develop, deploy, assess, or secure solutions that incorporate Docker 1.6 or later technology, the Center for Internet Security (CIS) has released its first security configuration benchmark for Docker 1.6, which makes more than 80 recommendations for configuring and operating Docker in production environments. The benchmark was created by consensus with representatives from Docker, VMware, Cognitive Scale, International Securities Exchange, Rakuten, and CIS.

The CIS Benchmark for Docker 1.6

The CIS benchmark covers eight categories of recommendations, which will cover herein shortly. The recommendations are also mapped to the CIS Controls to allow for consistency between these best practices.

1. Host Configuration

This section covers security recommendations that you should follow to prepare the host machine that you plan to use for executing containerized workloads. Securing the Docker host and following your infrastructure security best practices would build a solid and secure foundation for executing containerized workloads. The section includes best practices such as:

• Ensure that Docker is up to date to mitigate software vulnerabilities
• Ensure a separate partition for containers has been created to avoid the /var/lib/docker directory fill up quickly causing both Docker and the host to become unusable.
• Ensure only trusted users are allowed to control Docker daemon to minimize administrative privileges and only use administrative accounts when they are required.
• Ensure auditing is configured for the Docker daemon and the Docker files and directories to audit the activities and usage of the daemon which runs with root

2. Docker daemon configuration

This section lists the recommendations that alter and secure the behavior of the Docker daemon. The section includes best practices such as:

• Ensure network traffic is restricted between containers on the default bridge. Failure to do so might lead to an unintended and unwanted disclosure of information to other containers.
• Ensure Docker is allowed to make changes to iptables automatically in order to avoid networking misconfigurations that could affect the communication between containers and with the outside world. Additionally, this reduces the administrative overhead of updating iptables every time you add containers or modify networking options.
• Ensure insecure registries are not used. A secure registry uses TLS. An insecure registry is one which does not have a valid registry certificate, or one not using TLS. Insecure registries should not be used as they present a risk of traffic interception and modification.
• Ensure TLS authentication for Docker daemon is configured
• Enable “user namespace” support to provide additional security for the Docker host system by allowing a container to have a unique range of user and group IDs which are outside the traditional user and group range utilized by the host system.
• Ensure containers are restricted from acquiring new privileges. This reduces the security risks associated with many dangerous operations because there is a much reduced ability to subvert privileged binaries.

3. Docker daemon configuration files

This section covers Docker related files and directory permissions and ownership. Keeping the files and directories, that may contain sensitive parameters, secure is important for correct and secure functioning of Docker daemon. This is required to minimize administrative privileges and only use administrative accounts when they are required. These controls will enforce the principle that only authorized individuals should have access to the information based on their need to access the information as a part of their responsibilities.

4. Container Images and Build File Configuration

Container base images and build files govern the fundamentals of how a container instance from a particular image would behave. Ensuring that you are using proper base images and appropriate build files can be very important for building your containerized infrastructure. The recommendations include best practices such as:

• Running the container as a non-root user, where possible.
• Ensure content trust for Docker is enabled. Content trust provides the ability to use digital signatures for data sent to and received from remote Docker registries. These signatures allow client-side verification of the identity and the publisher of specific image tags and ensures the provenance of container images.
• Ensure that HEALTHCHECK instructions have been added to container images. An important security control is that of availability. Adding the HEALTHCHECK instruction to your container image ensures that the Docker engine periodically checks the running container instances against that instruction to ensure that containers are still operational.

5. Container Runtime Configuration

There are many security implications associated with the ways that containers are started. Some runtime parameters can be supplied that have security consequences that could compromise the host and the containers running on it. It is therefore very important to verify the way in which containers are started, and which parameters are associated with them. Container runtime configuration should be reviewed in line with organizational security policy.

• Ensure that, if applicable, an AppArmor Profile is enabled. AppArmor protects the OS and applications from various threats by enforcing a security policy which is also known as an AppArmor profile. Enabling this feature enforces security policies on containers as defined in the profile.
• Ensure that, if applicable, SELinux security options are set to add an extra layer of safety to the containers.
• Ensure that Linux kernel capabilities are restricted within containers, because otherwise they can give an attacker with access to a container the ability to create spoofed network traffic.
• Ensure that privileged containers are not used.
• Ensure sensitive host system directories, such as /, /boot, /etc are not mounted on containers. If sensitive directories are mounted in read-write mode, it could be possible to make changes to files within them. This has obvious security implications and should be avoided.
• Ensure SSH Daemon (sshd) is not run within containers, because it increases the complexity of security management.
• Ensure that the host’s network namespace is not shared. Selecting this option is potentially dangerous and could potentially carry out undesired actions, such as shutting down the Docker host. This option should not be used unless there is a very specific reason for enabling it.
• Ensure that the memory usage for containers is limited. Having no limit on memory usage can lead to issues where one container can easily make the whole system unstable and as a result unusable.
• Ensure that the container’s root filesystem is mounted as read only. This option reduces security attack vectors since the container instance’s filesystem cannot be tampered with or written to unless it has explicit read-write permissions on its filesystem folder and directories.
• Ensure that incoming container traffic is bound to a specific host interface. This interface might also be protected with services such as intrusion detection, intrusion prevention, firewall, load balancing, etc. to screen incoming public traffic.

6. Docker Security Operations

This section covers some of the operational security issues associated with Docker deployments. These are best practices that should be followed where possible. Most of the recommendations in this section simply act as reminders that organizations should extend their current security best practices and policies to include containers.

7. Docker Swarm Configuration

This section lists the recommendations that alter and secure the behavior of the Docker Swarm. If you are not using Docker Swarm then the recommendations in this section do not apply. When Docker swarm mode is enabled on a Docker engine instance, multiple network ports are opened on the system and made available to other systems on the network for the purposes of cluster management and node communications. Opening network ports on a system increases its attack surface and this should be avoided unless required.

8. Docker Enterprise Configuration

This section contains recommendations for securing Docker Enterprise components, such as to:

• Configure the LDAP authentication service
• Use external certificates and not the default, not secure self-signed certificates.
• Enable signed image enforcement which gives you more control over the validity and origination of your Docker images prior to deployment. Signed image enforcement can prohibit images that are unsigned, have malformed signatures, and/or compromised signatures from being deployed.
• Enable image vulnerability scanning against both the MITRE Common Vulnerabilities and Exposures (CVE) database and NIST National Vulnerability Database (NVD).

Conclusion

Should businesses follow the best practices recommended by CIS, they will have taken the most important steps to successfully hardening their Docker environments and protecting their critical business applications.

About the author: Anastasios Arampatzis is a retired Hellenic Air Force officer with over 20 years’ worth of experience in managing IT projects and evaluating cybersecurity. During his service in the Armed Forces, he was assigned to various key positions in national, NATO and EU headquarters and has been honoured by numerous high-ranking officers for his expertise and professionalism. He was nominated as a certified NATO evaluator for information security. Anastasios’ interests include among others cybersecurity policy and governance, ICS and IoT security, encryption, and certificates management. He is also exploring the human side of cybersecurity – the psychology of security, public education, organizational training programs, and the effect of biases (cultural, heuristic and cognitive) in applying cybersecurity policies and integrating technology into learning. He is intrigued by new challenges, open-minded and flexible. Currently, he works as a cybersecurity content writer for Bora and is a member of the non-profit organization Homo Digitalis.