Container Security Hardening

Security Hardening for Docker Container Running

To ensure secure running of the container, configure the following capability items based on service requirements. For details, see the official description.

• Enable the AppArmor capability. You can specify the AppArmor file when running the container to protect the Linux system and applications, because AppArmor provides security policies. Before enabling the AppArmor capability, enable the AppArmor function of the Linux kernel.
• Enable the SELinux capability. You can specify the SELinux configuration when running the container to improve security. Before enabling this function, you need to use --selinux-enabled to make the configuration take effect in the Docker daemon.
• Enable the live restoration function. You need to set --live-restore to depend less on the Docker daemon.
• Set system resource quotas for the container to prevent the container from exhausting the resources. System resources include but are not limited to CPU and memory.
• Do not run untrusted applications in the container.
• Do not listen to unnecessary ports in the container.
• Configure a proper CPU priority for the container.
• Mount the root file system of the container in read-only mode.
• Bind the imported container traffic to a specific host interface and configure a specified IP address for the port mapping of the container.
• Limit the number of file handles and fork processes used for container running.
• Enable the authentication and encrypted transmission mechanisms for container service ports for external listening to prevent service data from being stolen.
• Do not run the SSH server in the container.
• Do not share namespaces, including the network namespace, UTS namespace, and user namespace.
• Do not mount docker.sock to the container.
• Ensure that no user is added to the Docker user group.
• Exercise caution when configuring parameters such as environment variables and ConfigMaps during API call related to container or template creation or update, and ensure that secure images are used. Do not transfer sensitive information through environment variables or ConfigMaps to prevent sensitive data leakage or privilege escalation risks caused by improper configuration. You are advised to fully verify data before using it based on your services.

Security Hardening on Containerized Application Logs

If logs of a containerized application are printed to the standard output, the containerized application logs may fail to be wrapped, causing drive space exhaustion. You are advised to set the max-size and max-file parameters in the log-opts field in the /etc/docker/daemon.json configuration file based on service requirements. After Docker is restarted, the configuration takes effect for containerized applications created after the configuration is modified.

Host Security Hardening

• Create an independent partition for containers. The default Docker directory is /var/lib/docker. You are advised to create an independent drive partition for Docker to prevent the drive space occupied by containers from affecting the drive space used by other applications on the host.
• Perform security hardening on the Docker host. You are advised to perform security hardening on the host where the Docker container is running and periodically scan for vulnerabilities.
• Use the latest Docker version. You are advised to update the Docker version in a timely manner to prevent known vulnerabilities in the Docker software.
• Enable the audit function for the Docker daemon and key files. The audit function traces the root cause of an attack event. After this function is enabled, the system performance is affected. Determine whether to enable this function based on service requirements.

Security Hardening on the Docker Daemon

• Restrict network access between containers. By default, the Docker daemon allows containers to communicate with each other, which may cause information leakage. You are advised to add -icc=false to the Docker daemon.
• Prevent the remote access interface of the daemon from being enabled. Do not use the Docker Remote API service. Strictly control the read and write permissions on the docker.sock file and add only necessary users to the Docker user group. If the Docker Remote API service needs to be enabled, you are advised to use --authorization-plugin to enable fine-grained access control for the daemon.
• Limit the numbers of file handles and fork processes in the container. You are advised to add the nofile and nproc parameters in --default-ulimit to the Docker daemon to prevent the host from being attacked by fork bombs or file handle exhaustion. The limits on container resources must be evaluated based on services. If the limits are improper, the container cannot run. For example, --default-ulimit nofile=64:64 --default-ulimit nproc=512:512 indicates that the number of file handles of a single process is limited to 64, and the number of fork processes of a single UID user is limited to 512.
• Disable the userland proxy. You are advised to add --userland-proxy=false to the Docker daemon to reduce the attack surface.
• Enable the user namespace. After it is enabled, permissions of container users and host users are isolated. For example, enable this function in the Docker daemon using --userns-remap=defalut.
• Do not use the AUFS storage driver, because it is not supported.
• Configure the log driver. Determine whether to enable the log driver based on service requirements.
• Ensure that the permissions on the files used by the Docker daemon are minimized. If the Docker configuration file is maliciously used, the Docker daemon may be abnormal. The files and directories that require special attention include but are not limited to the following:

  /etc/docker/certs.d/, /etc/docker/daemon.json, /etc/default/docker, /usr/lib/systemd/system/docker.service, /etc/sysconfig/docker, /var/run/docker.sock, /etc/docker/, and /usr/lib/systemd/system/docker.socket