Container Security Protection – Container Service Security
Container Service Security
The security of the container management and orchestration service has a direct bearing on that of the container control plane. Take Docker for example. Whether the Docker daemon is properly configured determines the security of Docker to some extent. It is recommended that the following settings be configured when starting the Docker daemon:
(1) Restrict inter-container network traffic.
By default, all traffic between containers on the same host is permitted. This is the so-called blacklist mechanism, which allows users to add access control lists as required. To restrict communication between containers on the same host, the whitelist mechanism can be employed (by passing a command-line parameter –icc = false to the Docker daemon) to prohibit inter-container traffic by default. Containers can communicate with one another only after they are added to the whitelist. In addition, we can add containers to a custom network to restrict their communication with containers on other networks.
(2) Set remote, centralized log management.
Containers have a short lifecycle that is full of rapid service changes. To address this issue, we can put logs on a remote, centralized platform for security analysis and forensics by using docker –log-driver=syslog –log-opt syslog-address=tcp://192.xxx.xxx.xxx.
(3) Allow Docker to modify iptables rules.
The Docker daemon can automatically modify iptables as required according to users’ network configuration. It is recommended that the Docker daemon be allowed to automatically update the iptables configuration by setting docker –iptables to true.
(4) Do not use AUFS as the storage driver.
The advanced multi-layered unification filesystem (AUFS), as a rather old storage driver of Linux, may trigger some major issues such as kernel crash. Many new Linux kernel releases stop providing support for AUFS. Users can use the docker –storage-driver devicemapper command to specify the device mapper as the storage driver. By default, Docker on most platforms adopts the device mapper as the storage driver. This may vary with operating systems. The preferable choice goes for the best storage driver supported by the operating system.
(5) Use default cgroups.
Docker controls container resources with cgroups, which can be set with the docker –cgroup-parent = /foobar command line.
For configuration of the daemon, besides the preceding command line, another common operation is to modify the docker.service file, whose path is generally /lib/systemd/system/docker.service. The path may vary with Linux distributions. After the file is modified, the Docker daemon needs to be restarted to control resources with cgroups.
(6) Set ulimit at the Docker daemon level.
ulimit is a built-in function of Linux. It contains a set of parameters for controlling resources available for the shell or processes started by it. Resource types supported by ulimit include the size of kernel files created, size of process data chunks, size of files created by shell processes, size of locked memory, size of the resident memory set, number of opened file descriptors, maximum value of the allocated stack, CPU time, maximum number of stacks for a single user, and maximum virtual memory available for shell processes. ulimit has two types of settings: hard and soft.
Setting ulimits can be useful for avoiding resource exhaustion-caused problems, such as a fork bomb. Sometimes, legitimate users and process can also overuse system resources, leading to resource exhaustion. Therefore, it is necessary to control resource usage by setting default ulimits for the Docker service.
(7) Use trusted repositories.
By default, the Docker process allows push and pull of images only from repositories configured with trusted certificates. It is not advisable to enable this configuration item unless the untrusted repository to be used is built internally.
