Docker Docker Daemon Json Config

  

The daemon.json configuration sets the default for clients that support both the classic builder and BuildKit (such clients can still switch back to the old builder). I agree the docs should highlight that (in a comparison with compose v1), compose v2 will always use BuildKit. The preferred method for configuring the Docker Engine on Windows is using a configuration file. The configuration file can be found at 'C: ProgramData Docker config daemon.json'. You can create this file if it doesn't already exist.

Step 2 in the Windows setup for the ServiceNow® headless browser for Automated Test Framework.

Role required: admin on your ServiceNow® instance and local administrator on the host machine.

Complete Step 1: Generate certificates for headless browser setup for Windows

Procedure

  1. Configure Docker to use the certificates you generated in Step 1.
  2. Find or create the C:ProgramDatadockerconfigdaemon.json file.
  3. Add the following properties to the daemon.json file. Be sure to replace with the correct paths to your certificates:
    Note: The double slashes are important to copy exactly.
    To learn more, see https://docs.docker.com/config/daemon/#configure-the-docker-daemon.
  4. In administrator PowerShell run: restart-service *docker*

So in P3 of the Harden Docker with CIS series, I’ll continue with the hardening process of the Docker installation which we setup in the P1. We’ll start with the module two of the benchmark (CIS Docker Benchmark v1.2.0) i.e. Docker daemon configuration. There are seventeen items in total out of which one is “Not scored”, thus it will be not be entertained in detail in this post. In this port we’ll cover eight out of the total sixteen scored items, and the others will be covered in the next part. So let’s begin.

Not Scored

Scored

2.1 Ensure network traffic is restricted between containers on the default bridge

By default, all the containers in the default bridge can communicate with each other, without any restrictions. However this can be dangerous configuration if a malicious container is running on the default bridge as the other privileged containers. Thus, ensuring that “Inter container communication” (ICC) is turned off.

To verify if the ICC is turned off/on your Docker installation

As it is evident, in my Docker installation, ICC is turned on, thus containers can talk to each other, let’s see how this works.

As shown in the command line snippet above, we can ping, as well as curl the other container running nginx. Now let’s turn off ICC and try to do the same.

We can add our settings for the Docker daemon in the /etc/docker/daemon.json settings file, and then restart the Docker daemon with sudo systemctl restart docker and we can verify that if the settings took effect.

To turn off ICC, create daemon.json file it already doesn’t exist and then add the following content

After restarting the Docker daemon, let’s verify the settings.

So as ICC has been turned off, now let’s try and ping one container from the other.

NOTE: As we have restarted the Docker daemon, all the containers would have been stopped. So start all the containers (docker start $(docker ps -a -q)) before attempting anything.

So now after turning off ICC, containers can no longer communicate with each other.

2.2 Ensure the logging level is set to ‘info’

By default Docker daemon logging level is set to ‘info, however, we’ll be explicit and enable this setting in the /etc/docker/daemon,json file as well.

Add the following to change the logging level to ‘info’

2.3 Ensure Docker is allowed to make changes to iptables

Docker uses iptables to manage networking and other network related configurations, thus Docker daemon should be allowed to make changes to the iptables. By default, this setting is enabled, however, following the suit, we’ll be explicit.

2.4 Ensure insecure registries are not used

Insecure registries should not be used as they present a risk of traffic interception and modification. This can be mitigated using TLS communication, and ensuring that only secure registries are used to pull/push the images. By default Docker considers or looks for every registry to be trusted except the local one. The output of the following command should always only list one single registry i.e. local one.

If there are any registries other than the local one, then that registry should be removed.

2.5 Ensure aufs storage driver is not used

Daemon

This is an obsolete setting, as these days only overlay2 is used for Docker images and containers. Anime saiunkoku monogatari sub indo batch. However, it is still important to know how to look for this setting.

This is the expected output, if there is anything except overlay2, it should be changed to any of the available ones except aufs such as devicemapper, btrfs, zfs, overlay, overlay2, and fuse-overlayfs

2.6 Ensure TLS authentication for Docker daemon is configured

To avoid confusion and to ensure best suggested practices, I haven’t delved deep into this topic. Docker‘s official documentation about the topic should serve the purpose and provide up to date information as to how to setup certificates for Docker daemon.

Reference: https://docs.docker.com/engine/security/https/

2.8 Enable user namespace support

The best way to prevent privilege-escalation attacks from within a container is to configure your container’s applications to run as unprivileged users. This can be achieved using user-namespace remapping in Docker. There are a few prerequisites to enable this feature for Docker daemon, else default options can also be used to achieve the same. We’ll use the default option and for detailed process and other intricacies official document can be followed.

Add the following line to the /etc/docker/daemon.json file to enable user namespace remapping.

Docker Daemon.json Configuration

This will create a default (dockremap user) mapping and will be utilized to run containers. We can verify if this mapping was created by running a container (docker run hello-world) and verifying the contents of the /var/lib/docker directory.

As it is evident, the files in the folder 231072.231072 is owned by the 231072 user thus limiting escalation attacks from within the containers.

Docker Daemon.json Configuration Options

There are a few limitation to this approach as well, and ways to exclude running containers from this mapping. This is particularly true for containers that need to run as root. This can be referred to in the official documentation.

2.9 Ensure the default cgroup usage has been confirmed

Cgroups can be utilized to ration a lot of resources within the host operating system. Thus ensuring that Docker containers are running under a specific cgroup is important. By default Docker utilizes /docker for cgroup driver and system.slice for systemd cgroup driver.

Daemon

These settings can be changed, on container to container basis using --cgroup-parent flag while initiating a container, or can be changed globally by setting up the values in the /etc/docker/daemon.json file.

This completes the part 1 of our Docker daemon configuration section of the CIS Docker Benchmarks. We’ll continue with other controls in the next post.

Docker Docker Daemon Json Config File

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