Shulou(Shulou.com)06/02 Report--

This article shows you the security analysis of the Docker container, which is concise and easy to understand, which will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

Docker is one of the most representative container technologies, which has a subversive impact on cloud computing and virtualization technology. This paper studies the security problems and risks that Docker container may face in the application, and divides the security mechanism and related solutions in Docker container application environment into three parts: container virtualization security, container security management and container network security.

From Virtualization Security to Container Security 1. Traditional Virtualization Technology

Virtualization technology is an important technical means to realize the full utilization, rational allocation and effective scheduling of hardware infrastructure resources. For example, in a typical OpenStack-based IaaS service, cloud service providers can build resource pools by building device clusters and provide elastic virtualization of underlying resources such as servers, storage, and networks to tenants.

The traditional virtualization technology takes the virtual machine as the management unit, and each virtual machine has an independent operating system kernel and does not share the software system resources of the host, so it has good isolation and is suitable for multi-tenant scenarios in cloud computing environment.

2. Container technology

Container technology can be regarded as a lightweight virtualization way, which packages the application and the necessary execution environment into a container image, so that the application can run relatively independently in the host (physical machine or virtual machine). Container technology is virtualized at the operating system layer and can run multiple virtualized environments on the host kernel. Compared with the traditional application testing and deployment, the deployment of the container does not need to consider the compatibility of the running environment of the application in advance; compared with the traditional virtual machine, the container can run in the host without an independent operating system kernel, achieving higher running efficiency and resource utilization.

Docker is one of the most representative container platforms at present, it blurs the boundary between traditional IaaS and PaaS, and has the advantages of continuous deployment and testing, cross-cloud platform support and so on. In the container cloud environment based on Kubernetes and other container orchestration tools, container cloud can provide functions such as resource sharing and isolation, container orchestration and deployment, application support and so on.

Docker container technology takes the container in the host as the management unit, but each container shares the host kernel resources, and realizes the isolation and restriction of resources through the Namespaces and CGroups mechanisms of the Linux system respectively.

1) Namespaces

In order to ensure the resource isolation between container processes and avoid mutual influence and interference, the Namespaces (namespace) mechanism of the Linux kernel provides UTS, User, Mount, Network, PID, IPC and other namespaces to achieve six resource isolation functions, such as hostname, user rights, file system, network, process number, and inter-process communication. The isolation of the corresponding resource content can be achieved by calling the clone () function and passing in the corresponding system call parameters to create the container process, as shown in Table 1.

Table 1:Namespaces isolation mechanism

Namespace system call parameters isolate content Linux kernel version UTSCLONE_NEWUTS hostnames and domain names 2.6.19IPCCLONE_NEWIPC semaphores, information queues and shared memory 2.6.19PIDCLONE_NEWPID process numbers 2.6.24NetworkCLONE_NEWNET network devices, network stacks, ports and other 2.6.29MountCLONE_NEWNS mount points (file systems) 2.4.19UserCLONE_NEWUSER users and user groups 3.8

For a process, you can get the namespace isolation under the process by looking at the / proc/ [pid] / ns file, as shown in figure 1. Each namespace has a number that uniquely identifies it. If the two processes in the host point to the same number of namespaces, they are under the same namespace.

Figure 1: process namespace

2) CGroups

CGroups (Control Groups, control group) mechanism was first proposed by Google in 2006. At present, it is a mechanism of the Linux kernel, which can limit and record the physical resources (CPU, memory, Imacro, etc.) used by task groups (process groups or thread groups), and allocate resources to each container relatively fairly through a variety of metrics to prevent resource abuse.

In practical application, CGroups will create a hook for each executing task. When resource allocation is involved in the process of task execution, functions on the hook will be triggered and the corresponding resources will be detected, thus limiting and priority allocation of resources.

CGroups provides four functions: resource restriction (Resource Limitation), priority allocation (Prioritization), resource statistics (Accounting) and task control (Control). It includes blkio, cpu, cpuacct, cpuset, devices, freezer, memory, perf_event, net_cls, net_prio, ns, hugetlb and other subsystems. Each subsystem controls a resource independently. It can realize the functions of block device input / output limit, CPU usage control, generating CPU resource usage report, memory usage limit and so on. The specific functions of several major subsystems are shown in Table 2.

Table 2:CGroups subsystem

Subsystem function blkio sets input / output limits for block devices (such as disks, solid state drives, etc.) cpu controls task use of CPU through scheduler control task cpuacct generation task report on CPU resource usage cpuset allocates independent CPU and memory devices to task open or close task access to device freezer suspend or restore task memory sets task memory usage limit Generate a report of the task on memory resource usage 3. Security

The security differences between traditional virtualization technology and Docker container technology are mainly reflected in isolation, including process isolation, file system isolation, device isolation, inter-process communication isolation, network isolation, resource restrictions and so on.

In the Docker container environment, because each container shares the operating system kernel, and the container is only a number of processes running on the host, its security, especially its isolation, compared with the traditional virtual machine, there is a certain gap between theory and practice.

II. Security risk analysis of Docker containers

According to the main characteristics of Docker container and its practical problems in security application, the technical security risks that may exist in the application of Docker container technology are divided into image security risk, container virtualization security risk, network security risk and so on, as shown in figure 2.

Figure 2: container security risk classification

1. Image security risk

Docker image is a static representation of Docker container, and the security of the image determines the runtime security of the container.

The images in the official image repository Docker Hub of the Docker container may be uploaded by individual developers. They are rich in quantity and versions, but their quality is uneven, and there may even be malicious images containing malicious vulnerabilities, so there may be greater security risks. Specifically, the security risks of Docker images are distributed in many aspects, such as the process of creation, the source of acquisition, the way of acquisition and so on.

1) Dockerfile security issues

The generation of Docker image mainly includes two ways, one is to package the running dynamic container through the docker commit command, and the other is to create the Dockerfile file by executing the docker build command. To ensure the principle of minimum installation and take into account the ease of maintenance of containers, it is recommended to use Dockerfile files to build container images, that is, to add applications layer by layer on the basic image.

Dockerfile is a text file that contains commands for combining images. It generally consists of four parts: basic image information (FROM), maintainer information (MAINTAINER), image operation instructions (RUN, ADD, COPY, etc.), and container startup instructions (CMD, etc.). Docker can create container images by reading commands in Dockerfile.

The content of the Dockerfile file determines the security of the Docker image to some extent, and its security risks include, but are not limited to, the following situations:

If a vulnerability exists in Dockerfile or a malicious script is inserted, the generated container may also be vulnerable or maliciously exploited. For example, an attacker can construct a special Dockerfile zip file that triggers a vulnerability at compile time to gain privileges to execute arbitrary code.

If it is not specified in Dockerfile that USER,Docker will run the container created by the Dockerfile as root by default, if the container is attacked, the root access of the host may also be obtained.

If sensitive information such as a fixed password is stored in the Dockerfile file and released to the public, it may lead to the risk of data disclosure.

If unnecessary applications are added to the writing of Dockerfile, such as SSH, Telnet, etc., there will be a risk of expanding the attack surface.

2) Image loophole

For most general developers, it is usually necessary to obtain a series of basic images for deployment and further development of the container cloud. Therefore, the security of the basic image determines the security of the container cloud environment to a certain extent.

The security risks of image vulnerabilities include situations where the software in the image contains CVE vulnerabilities and attackers upload images with malicious vulnerabilities.

① CVE vulnerability

Because the image is usually composed of the basic operating system and all kinds of application software, the applications with CVE vulnerabilities will also introduce CVE vulnerabilities into the Docker images.

Images are usually obtained through official image repositories Docker Hub or third-party image repositories provided by NetEase, Aliyun, etc. However, according to the research on security vulnerabilities of images in Docker Hub, the average number of vulnerabilities in both community and official images is close to 200. common images, including nginx, mysql and redis, contain high-risk vulnerabilities.

② malicious vulnerability

Malicious users may upload images containing malicious vulnerabilities such as backdoors and viruses to the official image library. In June 2018, security vendors Fortinet and Kromtech found 17 Docker images on Docker Hub containing malicious programs for digital currency mining, which had been downloaded 5 million times. At present, due to the widespread application of Docker in the world, many attacks on Docker containers in the whole network are used for digital currency mining, which brings real economic benefits to attackers and damages the normal use of Docker users.

3) Image repository security

As a tool to build a private image storage repository, the application security of Docker Registry must also be guaranteed. The security risk of the image warehouse mainly includes the security risk of the warehouse itself and the transmission security risk in the process of image pull.

Self-security of the repository: if the image warehouse, especially the private image warehouse, is controlled by malicious attackers, the security of all the images will not be guaranteed. For example, if the private image warehouse opens port 2357 due to improper configuration, the private repository will be exposed to the public network, and attackers can directly access the private warehouse and tamper with the contents of the image, causing security risks to the images in the warehouse.

Image pull security: how to ensure the integrity of container images from the image repository to the client is also an important security issue for image repositories. Because the user pulls the image in clear text, if the user encounters a man-in-the-middle attack during the interaction with the image repository, the pulled image is tampered with or released maliciously in the process of transmission. it will cause security risks to both the image repository and the user. Docker has adopted content validation mechanism to solve the problem of man-in-the-middle attacks since version 1.8.

2. Security risk of container virtualization

Compared with traditional virtual machines, Docker container does not have independent resource configuration and does not achieve the isolation at the kernel level of the operating system, so there may be security risks caused by incomplete resource isolation and inadequate resource restrictions.

1) Container isolation problem

For Docker containers, because containers and hosts share the operating system kernel, there are security risks in isolation between containers and hosts, and between containers and containers, including process isolation, file system isolation, inter-process communication isolation and so on.

Although Docker basically isolates file system resources through Namespaces, there are still some important system file directories and namespace information, such as / sys, / proc/sys, / proc/bus, / dev, time, syslog, etc., which are not isolated, but share relevant resources with the host.

In view of the security risk of container isolation, there are mainly the following two kinds of isolation failures:

An attacker may achieve the purpose of attacking one of the containers by attacking the host kernel.

Because the file system of the host where the container is located is jointly mounted, containers controlled by malicious users may also access other containers or hosts through jointly mounted file systems, resulting in data security problems.

2) Container escape attack

Container escape attack means that the container takes advantage of system vulnerabilities to "escape" its own permissions to access the host and other containers on the host. Because the container and the host share the operating system kernel, in order to prevent the container from obtaining the root permission of the host, it is usually not allowed to run the Docker container in privileged mode.

In the case of container escape, the most famous is the shocker.c program, which scans the host file system violently by calling the open_by_handle_at function to obtain the target file content of the host. Because the previous version of Docker1.0 used blacklist policy to manage container capabilities (Capability), there was no restriction on CAP_DAC_READ_SEARCH capabilities, which gave shocker.c programs the ability to call open_by_handle_at functions, resulting in container escape. Therefore, the improper limitation of container capacity is one of the risk causes of safety problems such as container escape. Fortunately, Docker uses whitelist management for container capabilities in subsequent versions, avoiding the escape of containers created by default through shocker.c cases.

In addition, at the Black Hat USA 2019 meeting, researchers from Capsule8 also presented a number of Docker container engine vulnerabilities and container escape attacks, including CVE-2019-5736, CVE-2018-18955, CVE-2016-5195 and other vulnerabilities that may cause container escape.

CVE-2019-5736 is a security vulnerability in runC, resulting in Docker prior to 18.09.2 allowing malicious containers to overwrite runC binaries on the host. RunC is a CLI tool for creating and running Docker containers, and this vulnerability allows attackers to execute arbitrary commands on the host machine as root.

The CVE-2018-18955 vulnerability involves nested user namespaces in the User namespace, and the ID mapping mechanism for uid (user ID) and gid (user group ID) in the user namespace ensures that the permissions that the process has do not exceed the scope of its parent namespace. The vulnerability exploits a corrupted ID mapping when creating a child namespace of a user namespace to elevate rights.

The CVE-2016-5195 dirty cow (Dirty CoW) Linux kernel escalation vulnerability can enable low-privilege users to locally elevate rights on multi-version Linux systems, which may lead to container escape. The Linux kernel function get_user_page may have a race condition when dealing with Copy-on-Write, resulting in the opportunity to write data to the read-only memory area in the process address space, and attackers can further modify su or passwd programs to gain root privileges.

3) denial of service attack

Since the container shares hardware resources such as CPU, memory and disk space with the host, and Docker itself has no default restrictions on the resources used by the container, if a single container uses up the host's computing resources or storage resources (such as the number of processes, storage space, etc.), it may lead to a denial of service of the host or other containers.

① Computing DoS attack

Fork Bomb is a typical denial of service attack against computing resources, which can quickly create a large number of processes by calling the fork () system function recursively and infinitely. Because the total number of processes supported by the host operating system kernel is limited, if a container is attacked by Fork Bomb, it is possible that the host process resources are exhausted due to the creation of too many processes in the container in a short period of time, and the host and other containers cannot create new processes.

② storage DoS attack

For storage resources, although Docker achieves file system isolation through Mount namespaces, CGroups does not impose storage resource restrictions on a single container for AUFS file systems, so using AUFS as a storage driver has certain security risks. If a container on the host constantly writes files to the AUFS file system, it may result in insufficient space for the host storage device to meet the data storage needs of itself and other containers.

3. Network security risk

Network security risk is an important risk faced by all information systems in the Internet. whether it is physical devices or virtual machines, there are network security risks that are difficult to avoid completely. In the lightweight virtualized container network environment, the network security risk is more complex and serious than the traditional network.

1) Container network attack

Docker provides a variety of networking modes, such as bridging network, MacVLAN, overlay network (Overlay), etc., which can respectively realize the interconnection of containers in the same host, cross-host container interconnection, container cluster network and other functions.

① bridge mode

Docker defaults to bridge mode and uses iptables for NAT translation and port mapping. Docker connects all containers to a virtual bridge called docker0 through a virtual network interface as the default gateway of the container, which is directly connected to the host.

The data packets inside the container arrive at docker0 through the virtual network interface pair to realize the communication between different containers in the same subnet. In bridge mode, containers within the same host can communicate with each other, while the outside of the host cannot access the container through the IP address assigned to the container.

Due to the lack of network security management mechanism between containers, it is impossible to restrict the network access between containers in the same host. Specifically, because the containers are connected through the docker0 bridge of the host internal network to achieve routing and NAT conversion, if there is no firewall and other protection mechanisms between the containers, the attacker can use a container to carry out ARP spoofing, sniffing, broadcast storm and other attacks on other containers in the host, resulting in information disclosure, affecting the normal operation of the network and other security consequences.

Therefore, if multiple containers deployed on the same host machine are not properly configured for access control boundary isolation, there may be network security risks between containers.

② MacVLAN

MacVLAN is a lightweight network virtualization technology, which realizes the isolation from the physical network through the network interface connection with the host.

MacVLAN allows multiple network interfaces with independent MAC addresses to be configured for the same physical network card and IP addresses can be configured separately, thus realizing the virtualization of the network card. MacVLAN mode does not need to create a bridge, that is, it can connect to the physical network directly through the network interface without NAT translation and port mapping, and different MacVLAN networks cannot communicate on the layer 2 network.

However, there is no access control among the containers in the same virtual network, so the MacVLAN mode still has the security risk of internal network attacks similar to the bridge mode.

③ Overlay network

Overlay network architecture is mainly used to build distributed container clusters, to build virtual networks on the Underlay network between different hosts through VxLAN technology, to build cross-host container clusters, and to realize the communication between containers under the same Overlay network in different physical hosts.

Like other networking modes, the Overlay network does not control the connection between containers in the same network. In addition, because VxLAN network traffic is not encrypted, encryption needs to be selected when setting IPSec tunnel parameters to ensure the security of container network transmission.

Therefore, no matter what kind of network connection mode is adopted, it is difficult to avoid the security risk of mutual attacks between containers.

2) Network DoS attack

Due to the existence of network virtualization, container networks are faced with security risks of DoS attacks that are different from those of traditional networks. DoS attacks in Docker container networks can be divided into two main forms: internal threats and external threats.

Internal threat: for the Docker container network environment, DoS attacks can be carried out between containers within the host without going through the physical Nic. Attackers launching DoS attacks on other containers through one container may reduce the network data processing capacity of other containers. Therefore, there is a risk of DoS attacks between container virtual networks.

External threats: since all containers on the same host share the physical Nic resources of the host, if an external attacker uses a botnet containing a large number of controlled hosts to send a large number of packets to a target container for DDoS attacks, it may occupy the network bandwidth resources of the host, resulting in denial of service of the host and other containers.

Third, Docker container security mechanism and solution 1. Container virtualization security

In the traditional virtualization technology architecture, Hypervisor virtual machine monitor is the management and scheduling module of virtual machine resources. In the container architecture, because there is no Hypervisor layer, it is necessary to rely on the relevant mechanisms at the kernel level of the operating system to securely manage the container resources.

1) isolation and restriction of container resources

In terms of resource isolation, different from using virtualization technology to achieve kernel-level isolation of the operating system, Docker realizes the relative independence of resources between containers and hosts and between containers and containers through the Namespace mechanism of the Linux kernel. By creating its own namespace for each running container, it ensures that the running of the processes in the container will not affect the processes in other containers or hosts.

In terms of resource restrictions, Docker implements resource restrictions and audits of different containers in the host through CGroups, including balanced configuration of physical resources such as CPU, memory, and Ipool O, to prevent a single container from running out of all resources, resulting in denial of service of other containers or hosts, and ensuring the normal operation of all containers.

However, CGroups does not implement restrictions on disk storage resources. If a container in the host uses up all the storage space of the host, other containers in the host can no longer write data. The storage-opt= [] disk quota provided by Docker only supports the Device Mapper file system, while the disk quota mechanism adopted by the Linux system itself is based on the quota technology of users and file systems, so it is difficult to implement process-based or directory-based disk quotas for Docker containers. Therefore, consider the following methods to implement the disk storage limit of the container:

Create individual users for each container and limit disk usage per user

Select file systems such as XFS that support disk usage limits for directories

Create a separate virtual file system for each container by creating a fixed-size disk file, creating a virtual file system from that disk file, and then mounting the virtual file system to the specified container directory.

In addition, by default, the container can use all the memory on the host. A memory limit mechanism can be used to prevent a denial of service attack in which one container consumes all host resources, specifically by running the container with the-m or-memory parameter.

(command example: docker run [running parameters]-memory [memory size] [container image name or ID] [command])

2) Container capacity limit

The Linux kernel capability represents the system call permission that the process has, which determines the system call ability of the program.

The default capabilities of the container include CHOWN, DAC_OVERRIDE, FSETID, SETGID, SETUID, SETFCAP, NET_RAW, MKNOD, SYS_REBOOT, SYS_CHROOT, KILL, NET_BIND_SERVICE, AUDIT_WRITE, and so on, as shown in Table 3.

Table 3: container default capabilities

Container default function CHOWN allows arbitrary changes to the file UID and GIDDAC_OVERRIDE allows you to ignore the read, write, and Perform access check FSETID allow file modification retain setuid/setgid flag bit SETGID allow change process group IDSETUID allow change process user IDSETFCAP allow transfer or delete capabilities NET_RAW allow creation of RAW and PACKET socket MKNOD allow use of mknod to create specified files SYS_REBOOT allow use of reboot or kexec_loadSYS_CHROOT allow use of chrootKILL allow signal NET_BIND_SERVICE allow binding of commonly used ports Number (port number less than 1024) AUDIT_WRITE allows audit log to be written

If the capacity of the container is not properly limited, the following security risks may exist:

Internal factors: when running the Docker container, the isolation of the container may occur if the default kernel feature configuration is adopted.

External factors: unnecessary kernel functions may cause attackers to attack the host kernel through containers.

Therefore, improper configuration of container capabilities may expand the attack surface and increase the security risks faced by containers and hosts. When executing docker run commands to run Docker containers, you can add or delete container capabilities through-cap-add or-- cap-drop configuration APIs according to actual requirements.

(command example: docker run-- cap-drop ALL-- cap-add SYS_TIME ntpd / bin/sh)

3) mandatory access control

Mandatory access control (Mandatory Access Control, MAC) means that every subject (including user and program) and object has a fixed security tag. Whether the subject can operate on the object depends on the relationship between the security tag owned by the subject and the object. In the Docker container application environment, the access to resources of the container can be restricted by the mandatory access control mechanism. The mandatory access control mechanisms of Linux kernel include SELinux, AppArmor and so on.

① SELinux mechanism

SELinux (Security-Enhanced Linux) is the mandatory access control implementation of the Linux kernel, which is initiated by the National Security Agency (NSA) to restrict the resource access of the process, that is, the process can only access the file resources required by its task. Therefore, resource access to the Docker container can be controlled through SELinux.

When you start the Docker daemon daemon, you can use SELinux in the Docker container by setting the-- selinux-enabled parameter to true. SELinux can invalidate the classical shocker.c program and make it unable to escape from the Docker container to access host resources.

(command example: docker daemon-- selinux-enabled = true)

② AppArmor mechanism

Like SELinux, AppArmor (Application Armor) is also a mandatory access control mechanism of Linux, which controls the permissions of executable programs, such as directory and file read and write, network port access, read and write, and so on.

After Docker daemon starts, the default profile docker-default of AppArmor is automatically created in / etc/apparmor.d/docker. The container can be controlled by adding access control rules in the default profile, and other configuration files can be specified by-- security-opt when the container is started. For example, adding a line of deny / etc/hosts rwklx to the configuration file to restrict access to / etc/hosts can also invalidate shocker.c container escape attacks.

(command example: docker run-- rm-ti-- cap-add=all-- security-opt apparmor:docker-default shocker bash)

4) Seccomp mechanism

Seccomp (Secure Computing Mode) is a security feature provided by the Linux kernel, which can realize the construction of the sandboxie mechanism of the application and limit the scope of system calls that the process can make in the way of whitelist or blacklist.

In Docker, restrictions on system calls to processes in the container can be achieved by writing seccomp profile in json format for each container. In seccomp profile, the following behaviors can be defined to respond to a process's system call:

SCMP_ACT_KILL: when a process makes the corresponding system call, the kernel sends a SIGSYS signal to terminate the process. The process will not receive this signal.

SCMP_ACT_TRAP: when a process makes the corresponding system call, the process receives the SIGSYS signal and changes its behavior

SCMP_ACT_ERRNO: when the process makes the corresponding system call, the system call fails and the process receives the errno return value

SCMP_ACT_TRACE: when the process makes the corresponding system call, the process is tracked

SCMP_ACT_ALLOW: allows the process to perform the corresponding system call behavior.

By default, the default seccomp profile is used during the startup of the Docker container, and a specific seccomp profile can be used with the security-opt seccomp option.

(command example: docker run-- rm-it-- security-opt seccomp:/path/to/seccomp/profile.json hello-world) 2. Container security management

1) Image repository security

① content trust mechanism

Docker's content trust (Content Trust) mechanism protects the integrity of the image during the transfer between the image repository and the user. Currently, the content trust mechanism of Docker is turned off by default and needs to be enabled manually. When the content trust mechanism is enabled, the image publisher can sign the image, and the image user can verify the image signature.

Specifically, the image builder needs to enable the DOCKER_CONTENT_TRUST environment variable to 1 manually or scripted before running the Dockerfile file through the docker build command. After the content trust mechanism is enabled, push, build, create, pull, run and other commands are bound to the content trust mechanism. Only the images that have passed the content trust verification can run these operations successfully. For example, if the Dockerfile contains an unsigned base image, it will not be able to successfully build the image through docker build.

(command example: export DOCKER_CONTENT_TRUST = 1)

② Notary Project

Notary is a separate open source project spun off from Docker to provide security for data collection. Notary is used for the security management of published content, which can digitally sign the published content and allow users to verify the integrity and source of the content. The goal of Notary is to ensure the interaction between the server and the client using trusted connections, which is used to solve the security of Internet content distribution, and is not limited to container applications.

In the Docker container scenario, Notary supports the Docker content trust mechanism. Therefore, Notary can be used to build an image repository server to sign container images and provide better support for security requirements such as image source authentication and image integrity.

2) Image security scanning

In order to ensure the security of the container operation, it is necessary to check the security of the image when obtaining the image from the public image warehouse to prevent the operation of the image with security risks or even malicious vulnerabilities, and prevent the occurrence of security accidents from the source. Image vulnerability scanning tool is a kind of commonly used image security inspection tools, which can detect CVE vulnerabilities in container images.

For vulnerability scanning of Docker images, there are many related tools and solutions, including Docker Security Scanning, Clair, Anchore, Trivy, Aqua and so on.

① Docker Security Scanning Service

Docker Security Scanning is an official Docker vulnerability scanning service for non-open source images, which is used to check the security of images in private repositories and official Docker Hub repositories in Docker Cloud services.

Docker Security Scanning includes scan trigger, scanner, database, add-on framework and CVE vulnerability database peer-to-peer service. When a mirror in the repository is updated, the vulnerability scan is automatically started; when the CVE vulnerability database is updated, the image vulnerability scan results are updated in real time.

② Clair tool

Clair is an open source Docker image vulnerability scanning tool. Similar to Docker Security Scanning, Clair obtains the corresponding vulnerability analysis results by statically analyzing the Docker image and associating it with the public vulnerability database. Clair mainly includes the following modules:

Fetcher (acquirer): collects vulnerability data from common CVE leak sources

Detector (detector): scan each mirrored Layer to extract mirror features

Notifier (notifier): used to receive the latest vulnerability information from the public CVE vulnerability library by WebHook and update the vulnerability library.

Databases (database): layers and CVE vulnerabilities in the PostSQL database storage container

③ Trivy tool

Trivy is a simple and comprehensive open source container vulnerability scanner. Trivy detects vulnerabilities in operating system packages (Alpine, RHEL, CentOS, etc.) and application dependencies (Bundler, Composer, npm, yarn, etc.). In addition, Trivy is easy to use and can perform scanning simply by installing binaries and specifying the image name of the scanning container. Trivy provides rich functional interfaces. Compared with other container image vulnerability scanning tools, it is more suitable for automatic operation and can better meet the needs of continuous integration.

(command example: trivy [image name])

3) Container runtime monitoring

In order to ensure the safety of the container operation at the system operation and maintenance level, and realize the immediate alarm and emergency response of security risks, it is necessary to monitor the performance indicators of the Docker container in real time.

Tools and solutions for monitoring Docker containers include docker stats, cAdvisor, Scout, DataDog, Sensu, and so on, the most common of which are Docker native docker stats commands and Google's cAdvisor open source tools.

① docker stats command

Docker stats is a container resource usage statistics command provided by Docker, which can be used to manually monitor the resource usage of the Docker container on the host, including container basic information, container CPU utilization, memory utilization, memory usage and restrictions, block device iUnix O usage, network iUnix O usage, number of processes and other information. Users can set the format parameter to control the content format of the output of the docker stats command according to their own needs.

(command example: docker stats [Container name])

② cAdvisor tool

Because docker stats is only a simple command for viewing container resources, it is not highly visible and does not support the storage of monitoring data. CAdvisor is an open source container monitoring tool by Google, which optimizes the shortcomings of docker stats in visual display and data storage.

CAdvisor runs as a container on the host. By mounting the local volume, you can monitor and collect performance data of all containers running on the same host in real time, including CPU usage, memory usage, network throughput, file system usage and other information. It also provides local basic query interface and API interface to facilitate matching with other third-party tools. CAdvisor caches data in memory by default, and also provides different backend support for persistent storage, which can store monitoring data in databases such as Google BigQuery, InfluxDB or Redis.

CAdvisor is developed based on Go language and uses CGroups to obtain the resource usage information of the container. At present, it has been integrated into the Kubelet component in Kubernetes as the default startup item.

(command example: docker run-v/var/ run:/var/run:rw-v/sys:/sys:ro-v/var/lib/docker:/var/lib/docker:ro-p8080 v/sys:/sys:ro 8080-d-name cadvisor google/cadvisor)

4) Container security audit

① Docker daemon audit

In terms of security audit, for hosts running Docker containers, it is necessary to audit not only the host Linux file system, but also the activities of the Docker daemon. Because the system does not audit the Docker daemon by default, it needs to be done by actively adding audit rules or modifying rule files.

(command example: auditctl-w / usr/bin/docker-k docker or modify / etc/audit/audit.rules file)

② Docker related file directory audit

In addition to the Docker daemon, you also need to audit the files and directories related to the operation of Docker, as well as add audit rules or modify rule configuration files from the command line, as shown in Table 4.

Table 4:Docker related file and directory audit

File or directory remarks to be audited / var/lib/docker contains all information about the container / etc/docker contains keys and certificates for Docker daemon and client TLS communication docker.serviceDocker daemon running parameters profile docker.socket daemon running socket/etc/default/docker support Docker daemon various parameters / etc/default/daemon.json support Docker daemon various parameters / usr/bin/docker -containerdDocker available containerd generation container / usr/bin/docker-runcDocker available runC generation container

Docker and the Center for Internet Security (CIS) of the United States have jointly developed the Docker best security practice CIS Docker Benchmark, which is currently in version 1.2.0. To help Docker users check the security of the container environment they deploy, Docker officially provides Docker Bench for Security security configuration check script tool docker-bench-security, which is based on Docker best security practices established by CIS.

3. Container network security

1) flow restrictions between containers

Because the default bridge mode of Docker container does not control and restrict the network traffic, in order to prevent the potential risk of network DoS attacks, it is necessary to configure the network traffic according to the actual needs.

① completely prohibits communication between containers.

In a specific application scenario, if all containers in the host do not need network communication at layer 3 or layer 4, you can disable the communication between the container and the container by setting the-icc parameter of Docker daemon to false.

(command example: dockerd-- icc = false)

Flow control between ② containers

In a container cloud environment with multi-tenancy, there may be a situation where a single container occupies a large amount of host physical ENI to seize the bandwidth of other containers. In order to ensure the normal communication between containers and avoid network DoS attacks caused by abnormal traffic, it is necessary to limit the communication traffic between containers.

Because Docker connects the container with the virtual bridge docker0 by creating virtual network card pairs (eth0 and veth*), and the communication between containers needs to connect eth0 and veth* through the bridge through the virtual network card, the flow control module traffic controller of Linux can be used to limit the flow of the container network.

The principle of traffic controller is to establish packet queue and make sending rules to realize the function of traffic restriction and scheduling. In order to reduce the harm of DoS attacks between containers to a certain extent, the dev of traffic controller can be set as the veth* virtual network card connected to each container in the host, so as to limit the traffic between containers on the host machine.

2) Network access control in bridge mode

In the default bridge connection mode, two containers connected to the same bridge can access each other directly. Therefore, in order to achieve network access control, network access control mechanisms and policies can be configured as needed.

① creates different bridging networks for containers

In order to achieve network isolation between containers, containers can be placed in different bridging networks. When you use the docker network create command in Docker to create a new bridging network, DROP discarding rules will be added to DOCKER-ISOLATION in iptables to block the communication traffic with other networks and achieve the purpose of isolation between container networks.

(command example: docker network create-- subnet 102.102.0.0 Universe 24 test)

Network access Control of ② based on whitelist Policy

In order to ensure the network security between containers, you can disable the communication between containers by default, and then set network access control rules as needed.

Specifically, within the same virtual network, network access between different Docker containers can be controlled through iptables. When the-icc parameter of Docker daemon is set to false, the FORWARD chain policy of iptables discards all by default. At this time, the whitelist policy can be used to achieve network access control, that is, according to the actual needs, an access control policy can be added to the iptables to minimize the policy and reduce the attack surface.

3) Network access control in cluster mode

Unlike virtualized clusters established through OpenStack to isolate different tenants through VLAN, container clusters based on Overlay networks can be accessed directly by default between different containers in the same subnet within the same host.

To control the access of applications from the outside of the host to the internal container, you can manually add ACL access control rules to the DOCKER-INGRESS chain of the host iptables to control the access of the host's eth0 to the container, or deploy firewalls outside the host.

However, in a large container cloud environment, it is not realistic to configure iptables or update firewall manually because of frequent dynamic changes and updates of micro-services. Therefore, the container firewall in the container cloud environment can be implemented through micro-segmentation (Micro-Segmentation). Micro-segmentation is a fine-grained network segmentation isolation mechanism, which is different from the traditional network segmentation mechanism which takes the network address as the basic unit, micro-segmentation can be isolated with a single container, the same network segment container and container application as granularity, and the network access control between micro-segments is realized through the container firewall.

IV. Summary

Compared with virtualization technology, Docker container technology has the characteristics of agility and lightweight, and is irreplaceable in promoting cloud native applications. At the same time, the pursuit of high efficiency of container technology also sacrifices the security requirements such as isolation, and there is still a large gap compared with virtualization technology in terms of security, and it involves a wide range of aspects, such as container image security, kernel security, network security, virtualization security, runtime security and so on.

When applying container technology to deploy the system, we should fully evaluate the security risk, formulate the corresponding security requirements according to the application scenario, and integrate the relevant security solutions to form the best practice of container security application.

The above is the security analysis of Docker containers. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.