Docker host hardening guide

By Keren Pollack, on May 13th, 2019

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

 

Docker secure engine

 

Host hardening automation

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

 

Why we don’t let non-root users run Docker

Audit docker daemon Level 1 Docker daemon runs with ‘root privileges, so it is necessary to audit its activities and usage.

 

 

System auditing

 

Docker- audit and accountability

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

 

Docker- audit and accountability

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

 

Docker- audit and accountability

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

 

Docker- audit and accountability

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

 

Docker- audit and accountability

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

 

Docker- audit and accountability

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

 

Docker- audit and accountability

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

 

Containerd integration

 

 

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

 

Containerd integration

 

 

CLI tool for spawning and running containers

 

runC vulnerability

 

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.

 

Docker host REST API vulnerability