According to 2019 "cloud threat risk report" shows that container technology adoption has increased the chance of data leakage: The research team found that more than 40,000 container platform connected to the Internet using the default configuration, use the most simple search terms can be found,
· 23354 Docker containers, which mainland China a total of 6015 Docker container is exposed to the Internet, ranking first in all countries and regions.
· 20353 Kubernetes container, a total of 11,425 US Kubernetes container is exposed to the Internet, ranking first in all countries and regions.
The complexity of the cloud determines its most vulnerable : In the past 18 months, were disclosed 65% of network security incidents are caused by a configuration error, data leakage has become a cloud infrastructure by the first large consequences after.
Malicious software begins to extend to the cloud claws: Currently found 28 percent of organizations are mining malware C2 domain communication with encryption currency, and the domain name as a threat to the organization Rocke manipulated. The research team has been closely monitoring this organization and find a unique tactics, techniques and procedures it uses, can make or fail to uninstall agent-based cloud security tools.
How Docker container security reinforcement?
1) file-level protection system
file system read-only: Some Linux system kernel file system must mount the container environment, otherwise the process will strike the container. This gives malicious process very large convenient, but most of the running App in the container does not need to actually write data to the file system. Based on this situation, developers can use read-only mode when the mount.
2) Capability mechanism
Linux on Capability mechanism described is quite clear that in order to perform permission checks, traditional UNIX process to achieve two different classification, highly privileged process (user ID is 0, the super user or root), and a low-privilege process (UID is not zero). High-privilege process completely avoids all kinds of permission checks, while low-privilege process will have to accept all permission checks, will be examined such as UID, GID and group list is valid. From the start of the 2.2 kernel, Linux and the advanced permissions original super-user related divided into different units, called Capability, so that you can separate specific Capability enabled or disabled.
Generally speaking, unreasonable ban Capability, would cause the application to crash, so for such containers Docker, both to safety, but also to ensure its availability. Developers need a multi-disciplinary trade-off Capability settings from the functionality, availability, and security.
3) NameSpace mechanism
Some also provide namespace Docker provides security to some extent, such as PID namespace, it will not run all the developers in the current container hidden process. If a malicious program to see can not see these processes, it will be some trouble. In addition, if a developer is to terminate the process pid 1 namespace, all the processes inside the container will be automatically terminated all, which means that administrators can easily turn off the container. There are also network namespace for administrators to build a network environment container by routing rules and iptable, this process inside the container can only use a specific network administrator permission. The container for filtering content between only to the public network, and only access the local two containers.
4) Cgroups mechanism
is mainly directed against denial of service. Malicious process will be carried out by all of the system resources occupied system. Cgroups mechanisms to avoid this from happening, such as the CPU may be trying to undermine the cgroups CPU time to log in and stop malicious processes in a Docker container. We need to design more cgroups, to control those resources to open too many files or too many sub-processes, etc. process.
5) SELinux
SELinux is a label system, process label each file, directory, system objects have labels. SELinux security to protect the access rules by writing process between the label and label objects. It implements a system called MAC (Mandatory Access Control), that the owner of the object can not control other people to access the object.
6) Docker safe to rely on other supporting mechanisms
If you insist on using root access Docker Engine, system security may be affected by a series of well-known kernel security vulnerabilities. It is particularly recommended that:
· running AppArmor or SELinux while running Docker Engine system.
· The machine into different groups, each container drawn in a trust group.
• Do not run any untrusted applications with root privileges.
· Safeguard mechanism.
To keep order to detect the wheel, to be able to detect suspicious behavior, and have a response to any suspicious behavior. A process such as not to root privileges, but later found it by detecting mechanism becomes a root privileges, we can suspect that it is right to mention the illegal operation. In other words, we allow you to escape, but we can also find your escape behavior in the shortest possible time, and to stop you.
In addition, there are still security Docker in a few urgent reinforcement: login process using clear text username and password, Image distribution certification, Docker to Host escape (published the vulnerability), within the Docker to the root account the availability of tenant , Docker's quota (disk, network), in the case of restrictions Docker (SELinux / AppArmor / gRSecurity) after lifting weights, access Docker traffic monitoring and auditing, there AUFS point.
Of course, the vast majority of Docker security issues are being used to appear in public cloud environments, if Docker is used in a private cloud environment, then the benefits it brings far more problems than it brings in.