Harden Docker with CIS – (P2) Host configurations

So in P2 of the Harden Docker with CIS series, I’ll start with the hardening process of the Docker installation which we setup in the P1. We’ll start with the module one of the benchmark (CIS Docker Benchmark v1.2.0) i.e. Host Configurations. There are thirteen items in total out of which three are “Not scored”, thus will be not be entertained in detail in this post. I have planned to primarily focus on “Scored” items for now. So let’s begin.

Not Scored

CIS ControlDescription
1.1.1Ensure the container host has been Hardened
1.1.2Ensure Docker is up to date

As evident from the description of the items, these are very broad strokes and are dependent on a lot of detailed processes. Thus, we will not be evaluating these items in detail. However, their explanation and rationale can be found in the CIS benchmark PDF.

Scored

CIS ControlDescription
1.2.1Ensure a separate partition for containers has been created (Ignored)
1.2.2Ensure only trusted users are allowed to control Docker daemon
1.2.3Ensure auditing is configured for the docker daemon
1.2.4Ensure auditing is configured for Docker files and directories – /var/lib/docker
1.2.5Ensure auditing is configured for Docker files and directories – /etc/docker
1.2.6Ensure auditing is configured for Docker files and directories – docker.service
1.2.7Ensure auditing is configured for Docker files and directories – docker.socket
1.2.8Ensure auditing is configured for Docker files and directories – /etc/default/docker
1.2.9Ensure auditing is configured for Docker files and directories – /etc/sysconfig/docker
1.2.10Ensure auditing is configured for Docker files and directories – /etc/docker/daemon.json
1.2.11Ensure auditing is configured for Docker files and directories – /usr/bin/containerd
1.2.12Ensure auditing is configured for Docker files and directories – /usr/sbin/runc

1.2.2 Ensure only trusted users are allowed to control Docker daemon

By default only the root user is allowed to interact with the Docker Daemon, thus making Docker daemon a high privileged process. Apart from root, members of the docker group are also allowed to interact with the daemon, along with people in the sudo group.

Thus, it is absolutely necessary to ensure that only privileged users have access to the root account, sudo group, and docker group. As the CIS docker benchmark has hardened host OS as a requirement, we’ll skip the discussions around root account access, as well as the access to the sudo group, which should be part of the OS hardening process. Let’s move on to docker group, how to check which members have access, and how to add/remove the users from this group.

Check the group members of the docker group

[email protected]:~$ getent group docker docker:x:998:debian
Code language: Bash (bash)

Add new users to the group

[email protected]:~$ sudo usermod -aG docker docker-user-1 [email protected]:~$ getent group docker docker:x:998:debian,docker-user-1 [email protected]:~$
Code language: Bash (bash)

Remove users from the group

[email protected]:~$ sudo deluser docker-user-1 docker Removing user `docker-user-1' from group `docker' ... Done. [email protected]:~$ getent group docker docker:x:998:debian
Code language: Bash (bash)

NOTE: This point on, everything is about enabling different types of auditd rules and ensuring that they are working fine. Please make sure that you have auditd installed on your system.

Let’s verify if the auditd system service is enabled and running after our installation

[email protected]:~$ sudo systemctl status auditd ● auditd.service - Security Auditing Service Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2020-12-05 15:06:47 UTC; 2min 29s ago Docs: man:auditd(8) https://github.com/linux-audit/audit-documentation Main PID: 16419 (auditd) Tasks: 2 (limit: 1166) Memory: 948.0K CGroup: /system.slice/auditd.service └─16419 /sbin/auditd
Code language: Bash (bash)

As we can see the service is active, we are good to move on with our auditing configurations.

1.2.3 Ensure auditing is configured for the docker daemon

Let’s verify if there are any rules for Docker binary

[email protected]:~$ sudo auditctl -l | grep /usr/bin/dockerd [email protected]:~$
Code language: Bash (bash)

As there was no output, we can be sure that logging for the /usr/bin/dockerd binary is not set up. So now, let’s set it up.

Let us append -w /usr/bin/dockerd -k docker to the audit rules file, situated at /etc/audit/rules.d/audit.rules and then restart the service sudo systemctl restart auditd and now let’s verify if we have the rule in place.

[email protected]:~$ sudo auditctl -l | grep /usr/bin/dockerd -w /usr/bin/dockerd -p rwxa -k docker
Code language: Bash (bash)

As evident, we have set up the auditing for Docker daemon.

1.2.4 – 1.2.12 Enable auditing for critical docker folders, files, and sockets.

Let’s append the following lines in the /etc/audit/rules.d/audit.rules file and restart the auditd service.

# It holds all the information about containers. -w /var/lib/docker -k docker # It holds various certificates and keys used for TLS communication between Docker daemon and Docker client. -w /etc/docker -k docker # The docker.service file might be present if the daemon parameters have been changed by an administrator. It holds various parameters for Docker daemon -w /usr/lib/systemd/system/docker.service -k docker # It holds various parameters for Docker daemon socket -w /usr/lib/systemd/system/docker.socket -k docker # It holds various parameters for Docker daemon. -w /etc/default/docker -k docker ## For Cent-OS and RHEL based systems # it contains various parameters related to the Docker daemon when run on CentOS and RHEL based distributions -w /etc/sysconfig/docker -k docker # It holds various parameters for Docker daemon. -w /etc/docker/daemon.json -k docker # Docker relies on containerd and runC to spawn containers -w /usr/bin/containerd -k docker -w /usr/sbin/runc -k docker # Restart the auditd service and we are good sudo systemctl restart auditd
Code language: Bash (bash)

This completes our Host configuration section of the CIS Docker Benchmarks. We’ll continue with the other sections in future posts.

If you have questions or need help setting things up, reach out to me @jtnydv