Share
Containerization, which allows organizations to better their IT network effectiveness, is without a doubt a hot topic nowadays. But many of those embracing containers are unaware that misconfiguration of the container hosts can lead to an attacker having domain administrator privileges and potentially harming the entire IT network infrastructure.
Securing your container hosts’ configurations is essential. The Center for Internet Security benchmarks which serve as guidelines for both Docker and Kubernetes hosts’ configurations settings.
The following table presents the configuration value, it’s importance level, the rationale behind it and links with useful information.
| Configuration
|
Ranking level
|
Rationale
|
Guides
|
| Create a separate partition for containers | Level 1 | All Docker related files (including images) depend on /var/lib/docker as a default directory. However, this directory might fill up fast, resulting in Docker and the host becoming unusable. For that reason, creating a separate partition for the docker file is recommended.
|
Setting up storage |
| Harden the container host | Level 1 | Host vulnerabilities should be mitigated by hardening the host. Skipping this stage will expose you to security breaches. You should follow hardening best practices such as the CIS benchmark for the specific host.
|
CIS benchmarks
|
| Keep Docker up to date | Level 1 | Not installing the latest Docker updates may leave you running a vulnerable Docker version and being exposed to breaches. By staying up to date on Docker updates, known vulnerabilities might be mitigated.
|
How to update Docker to the latest version |
| Only allow trusted users to control Docker daemon | Level 1 | Docker allows you to share a directory between the host and the guest container without limiting the access rights of the container. That means that the container is able to change the host file system without any restrictions. As a result, you can attain elevated privileges by just being a member of the ‘docker’ group and can start a container with mapped / directory on the host.
|
Protect the Docker daemon socket
‘docker’ group considered harmful
|
| Audit docker daemon | Level 1 | Docker daemon runs with ‘root privileges, so it is necessary to audit its activities and usage.
|
System auditing
|
| Audit Docker files and directories- /var/lib/docker | Level 1 | Docker daemon (running with ‘root’ privileges) depends on some key files and directories. One of them is /var/lib/docker. This directory holds all the information about containers, and therefore must be audited.
|
System auditing
|
| Audit Docker files and directories- /etc/docker | Level 1 | Docker daemon (running with ‘root’ privileges) depends on some key files and directories. One of them is /etc/docker. This directory holds various certificates and keys used for TLS communication between Docker daemon and Docker client, and therefore must be audited.
|
System auditing
|
| Audit Docker files and directories- docker.service | Level 1 | Docker daemon (running with ‘root’ privileges) depends on some key files and directories. One of them is docker.service. This file might be presented if the daemon parameters have been changed by an administrator, and therefore must be audited.
|
System auditing
|
| Audit Docker files and directories- docker.socket | Level 1 | Docker daemon (running with ‘root’ privileges) depends on some key files and directories. One of them is docker.socket. This file holds various parameters for Docker daemon socket, and therefore must be audited.
|
System auditing
|
| Audit Docker files and directories- /etc/default/docker | Level 1 | Docker daemon (running with ‘root’ privileges) depends on some key files and directories. One of them is /etc/default/docker. This file holds various parameters for Docker daemon, and therefore must be audited.
|
System auditing
|
| Audit Docker files and directories- /etc/docker/daemon.json | Level 1 | Docker daemon (running with ‘root’ privileges) depends on some key files and directories. One of them is /etc/docker/daemon.json. This file holds various parameters for Docker daemon, and therefore must be audited.
|
System auditing
|
| Audit Docker files and directories- usr/bin/docker-containerd | Level 1 | Docker daemon (running with ‘root’ privileges) depends on some key files and directories. One of them is usr/bin/docker-containerd. Docker relies on containerd & runC to spawn containers, and therefore must be audited.
|
System auditing
Docker- audit and accountability
|
| Audit Docker files and directories- usr/bin/docker-runC | Level 1 | Docker daemon (running with ‘root’ privileges) depends on some key files and directories. One of them is usr/bin/docker-runC. Docker relies on containerd & runC to spawn containers, and therefore must be audited. | System auditing
Docker- audit and accountability
CLI tool for spawning and running containers
|
One of the most critical but challenging tasks in this guide is the hardening container host. Whether your container host is based on Linux or Windows OS, hardening it is a completely separate challenge, often a hard, costly and time consuming one.
In order to achieve host hardening, you need to follow best practices benchmarks, such as CIS benchmarks or DISA STIG. These benchmarks often delivered by several hundred pages files with dozens of rules to follow. Each rule can affect differently on production environment; therefore, lab testing needs to be done before applying each rule or changing the production environment.
With CHS by CalCom hardening is no longer an issue. CHS will ‘learn’ your production environment dependencies and automatically inform you if any hardening action can cause outages to it. Based on best practices benchmarks CHS will ensure everlasting compliance with no need for lab testing and no risk for configuration drifts.
