Rules for Setting Daemon Parameters

Restricting Uncontrolled Network Communication Between Containers

Because Docker containers share the host kernel, to clearly define the responsibilities of each container in a multi-tenant environment, it is a good practice to deploy containers on a host that is dedicated for the containers and is not used for sensitive operations. You can migrate all services to Docker-controlled containers. Network communication between containers on the same host is not restricted. Therefore, each container can read all packets on the container network of the same host. This may cause the data in a container to be accidentally leaked to other containers. Therefore, communication between containers must be restricted.

Generally you need to perform the following operations:

1. Open the /lib/systemd/system/docker.service file.

   vim /lib/systemd/system/docker.service

2. Press i to enter the insert mode and add parameter --icc=false to the end of ExecStart in the file. The following uses Ubuntu as an example.

   1	ExecStart=/usr/bin/dockerd -H unix:///var/run/docker.sock --selinux-enabled=false --icc=false

3. Press Esc, type :wq!, and press Enter to save the file and exit.
4. Restart the Docker service.

   1 2	systemctl daemon-reload systemctl restart docker

   

   Run the following command to check whether the previous modification is successful.

   1	ps -ef|grep docker

   If the process startup parameter in the command output contains --icc=false, the modification is successful.

Disabling the Remote API to Prevent the Docker Daemon from Being Exposed to an External Network

By default, the Docker daemon is bound to a non-networked UNIX socket and runs with root privileges, for example, unix:///var/run/docker.sock.

The official website also provides a RESTful API that allows remote access to Docker through TCP. For example, the following startup parameter can be executed to enable Docker to listen to port 2375 of all local addresses:

1

dockerd -H=0.0.0.0:2375 -H unix:///var/run/docker.sock

It is very dangerous to enable the Docker remote API service without any access control, specifically, binding the Docker daemon to a TCP port or another UNIX socket. Anyone who accesses the port or socket has permission to access the Docker daemon. Attackers can use a Docker client or any HTTP client to remotely access the Docker daemon, access the host system, and easily grab the access to the entire server.

Therefore, note the following:

1. Do not bind a local Docker daemon to a TCP port or another UNIX socket.
2. Do not enable the remote API service of Docker unless when it is needed.

Disabling the Userland Proxy

The Docker engine provides two mechanisms for forwarding ports from the host to containers: hairpin NAT and a userland proxy. In most circumstances, the hairpin NAT mode is preferred as it improves performance and makes use of native Linux iptables functionality instead of an additional component. Where hairpin NAT is available, the userland proxy should be disabled on startup to reduce the attack surface of the installation.

Generally you need to perform the following operations:

1. Add --userland-proxy=false to the end of the ExecStart item in the /lib/systemd/system/docker.service file.
2. Restart the Docker service.

   1 2	systemctl daemon-reload systemctl restart docker

   

   Run the following command to check whether the previous modification is successful.

   1	ps -ef | grep docker

   If the process startup parameter in the command output contains --userland-proxy=false, the modification is successful.

Enabling the User Namespace

The user namespace provides additional security for the Docker host system. It leverages the remapping mechanism from container users to the host to isolate permissions between container and host users. In other words, the containers can have UIDs and GIDs that are different from those in the host system. For example, the root user in a container may be a non-root user in the host system. This allows processes to run with the root privileges in a container, but the container does not have the root privileges in the host system. This recommendation is beneficial where containers you are using do not have an explicit container user defined in the container image. If container images that you are using have a pre-defined non-root user, you can skip this recommendation.

The user namespace is not enabled for Kbox. This recommendation conflicts with Creating an Independent Partition for Containers. Determine whether to configure the user namespace based on your site requirements.

Enabling Fine-grained Access Policy Control for the Daemon

The default authorization model of Docker is All or Nothing. Any user with access to the Docker daemon can run any Docker client command. The same is true for callers using Docker's remote API to contact the daemon. If you require greater access control, you can create authorization plugins and add them to your Docker daemon configuration. Using an authorization plugin, a Docker administrator can configure fine-grained access policies for managing access to the Docker daemon. By default, no authorization plugins are configured.

Fine-grained access policy control of the daemon is not enabled for Kbox. You can perform the following steps to enable the fine-grained access policy control:

1. Install and create an authorization plugin.
2. Configure an appropriate authorization policy.
3. Start the Docker daemon.

   1	dockerd --authorization-plugin=<PLUGIN_ID>

   

   Run the following command to check whether the previous modification is successful.

   1	ps -ef | grep docker | grep '\-\-authorization-plugin'

   If the command output is not empty, the modification is successful.

Configuring Centralized and Remote Logging

Centralized and remote logging ensures that all important log records are safe despite catastrophic events. Docker now supports various such logging drivers. Use the one that best suits your environment.

Generally you need to perform the following operations:

1. Add --log-driver=syslog to the end of the ExecStart item in the /lib/systemd/system/docker.service file.
   

   If ExecStart contains the --log-opt max-size=1g parameter, delete --log-opt max-size=1g and then add --log-driver=syslog.

2. Restart the Docker service.

   1 2	systemctl daemon-reload systemctl restart docker

   

   Run the following command to check whether the previous modification is successful.

   1	ps -ef | grep docker

   If the process startup parameter in the command output contains --log-driver=syslog, the modification is successful.

Enabling Live Restore

The --live-restore parameter allows the container to depend less on the Docker daemon. This parameter allows for container self-recovery and connection reestablishment upon a container restart without the need of stopping or disabling the container. In addition, --live-restore is an important security group policy, which allows a container to keep running even if the Docker daemon shuts down. It lets the Docker daemon upgrade and install patches without affecting any running container. This parameter is not configured by default.

Generally you need to perform the following operations:

1. Add --live-restore to the end of the ExecStart item in the /lib/systemd/system/docker.service file.
2. Restart the Docker service.

   1 2	systemctl daemon-reload systemctl restart docker

   

   Run the following command to check whether the previous modification is successful.

   1	ps -ef | grep docker

   If the process startup parameter in the command output contains --live-restore, the modification is successful.

Enabling TLS Authentication for TCP Remote Access

By default, the Docker daemon is bound to only one local socket. If remote access to the Docker daemon is required, enable TLS authentication.

Disabling Experimental Features in the Production Environment

Experimental features of Docker have not been fully tested. Their APIs are unstable. Do not use experimental features in the production environment.