Technical Q & A: How to view container security
Docker container technology is in full swing, and related security technologies are constantly advancing. We are also continuing to explore the application and security of container technology. This topic is from the traditional security perspective, hoping to bring you some thoughts and discussions.
1
From the traditional perspective, security is not only a technical issue, but also a matter of consciousness.
In the cloud era, service migration to the cloud is already very common. The Security penetration attack technology is also highly automated, with more targets under attack. At the same time, the attacker's technical means have increased, making the security environment of our cloud services unpredictable.
In the traditional cloud deployment mode, such as cloud platform SERVER + database + web + nginx, when security alerts are triggered, we can upgrade the kernel, patches, and services step by step, everything is easy.
When we apply the container technology to deployment and O & M, the packaging and migration are centered around docker and image, which avoids migration when copying the running environment. This new method brings new security challenges when there are security alerts without handling conventions or guidelines. 1
We regard traditional attack targets as a city or castle, and containers are the rooms in the city. Traditional methods include information collection, vulnerability discovery, and penetration infiltration.
From the perspective of containers, we can find the information in the room. The information is related to the city pool itself or is invisible, so as to obtain the secrets of the entire system structure.
In the process of penetration, vulnerabilities are particularly important for subsequent intrusion. In turn, how to promptly discover and handle system vulnerabilities is an important part of service security for enterprises. 1
Regardless of the vulnerability type, there is always a validity period. After the product is released, the penetration personnel will discover the vulnerability, submit the vulnerability library, or zero-day patch vulnerabilities.
After the vendor is notified or discovered by itself, the patch is upgraded, the user is upgraded, the software or image is updated, and the patch is completed. From the time when a penetration engineer discovers a vulnerability to the time when the vendor upgrades and releases the patch, this time is 0 day, causing great harm.
The traditional mode is different from the container mode. The traditional manufacturer maintains and upgrades the corresponding services in a timely manner and ensures high security. However, for containers, the security of basic images is limited, and the image sources are also different. At present, the level of image maintenance and upgrade is also uneven, and the security is unpredictable.
In terms of global policies, I think this is an important reason for the question of container security. 1
Let's take a look at some of the statistics made by foreign cool people, saying that there are more than 30% official container images on Docker Hub, including high-risk security vulnerabilities, including ssh heartbleed and bash shell-breaking vulnerabilities. For images submitted by common users, this ratio exceeds 40%, and the sampling error is 3%.
The data is deployed on these images, and then compared with the Common Vulnerabilities and Exposures in the Common Vulnerability Database CVE (Common Vulnerabilities and Exposures). The CVE has been rated in the corresponding libraries, high, Medium, low.
The first group of data looks terrible, because high-risk images are images that people often download. Then, the second group created a high-risk image of 40% this year, with a high-risk and medium-risk image of 75%. This may also be because of the sudden increase of active Docker users this year, the surge in image push volume, and the poor image security quality. The last group is marked with latest, which is the latest version of the image, which has dropped a lot. This also means that the version update will solve some problems. It also reminds us that latest is recommended for images and is updated frequently. 0
This figure compares the number of packages used by unofficial images. From this figure, we can see that the top three are bash apt openssl, this is probably because many images use basic ubuntu images, that is why bash ssh accounts for a large proportion in the image vulnerability.
List several recent CVE 0
These are docker's problems. The vulnerabilities in version 1.6.1 are basically Elevation of Privilege vulnerabilities. They can be exploit through well-designed images.
In addition to these CVE, there are also some security risks during the use of Docker. For example, if the disk quota is insufficient, docker itself does not have this function. In multi-tenant mode, if an application overwrites the disk, it will seriously affect the running of other container applications, it needs to be solved through auxiliary means. Then, the super permission-privileged, which grants the root capacity of all hosts of the container to be mounted to all devices at the same time. We all know that it is generally not recommended.
Let's take a look at the Docker security mechanism. Docker uses the kernel security mechanisms, including Capability, Namespace, and Cgroups. SELinux/appArmor belongs to the access control series. 0
Capability is used to restrict the capabilities of a container, that is, the permissions for executing certain system operations. You can also increase or decrease the capabilities of the container as needed. Namespace provides an isolated system runtime environment for each container, including pid, network, uts, ipc, and mount. Cgroup is mainly used to restrict the resources used by containers, including cpu and memory. Technically, you can restrict permissions and resources, use cap-drop to reduce capabilities, and use cgroup to add cpu and memory limits to containers. These users who are familiar with Docker should be familiar with it.
Through these security mechanisms and parameter settings, we can have a basic security control over docker itself. The Docker community is constantly striving for its own security. 0
First, in the open-source community, code contributors are specified with guidelines for code submission to reduce bugs and vulnerabilities during development and improve product quality. At the same time, conduct penetration tests on products on a regular basis to audit security vulnerabilities in a timely manner. The platform is opened to encourage Security penetration personnel to submit vulnerabilities. The official website also provides detection tools to provide a preliminary security risk assessment for the deployment and running environment of docker.
Docker inspect For Security is an integrated script, which will be initially detected in several aspects:
1-Host Configuration docker checks whether the partition location and kernel version comply with the standard
2-Docker Daemon Configuration checks Daemon Configuration, device driver, registry, TLS verification, etc.
3-Docker Daemon Configuration Files check related File Permissions
4-Container Images and Build Files Container User check, it is recommended that not root
5-Container Runtime Container SELinux/appArmor configuration, resource restrictions and File Mounting Permissions
6-Other Docker Security Operations Security Options
For image images, Docker1.8.0 provides the Docker Content Trust, allowing you to check the legitimacy of the container images before downloading it on the Docker Hub. Two keys are used for signature and verification to prevent Image tampering. 0
In my opinion, users should adopt traditional security thinking and new technical means to deal with container security issues.
In addition to the specific security settings described above, for container applications, the policy is also implemented in three aspects: 1. regular penetration tests and security audits (same as docker community practices); 2. try to use the formal image source of the image. Compared with traditional security, container security is challenged to a large extent because of the image maintenance and upgrade. Therefore, ensure security and timely update at the image source; 3. upgrade the container service in a timely manner, such as using rollingupdate to upgrade the container running the service.
Finally, although there are still problems in security, we can see that docker has a high degree of attention and activity in the open-source community, and there are many contributors. When everyone is working together, the development of docker container technology will inevitably improve. The existing problems will also be gradually overcome.
As this technology is gradually accepted and applied by the public, cloud container applications will gradually become more extensive. In addition, penetration security personnel will gradually become familiar with docker. In the future, there will be a concentrated burst time for docker security issues. However, the subsequent improvements and upgrades of docker, coupled with the improvement of the image security mechanism, will gradually reduce security issues.
Q &:
A: Well, it will be mentioned later that security monitoring should be appropriate.
A: It seems to be updated. Of course, these are just the initial security assessment of docker runtime environment configuration parameters. To detect the entire system service, you must use a dedicated penetration tool.
A: We use docker index instead of nginx authentication. Let's take a look at our video course "deep dive into Docker Registry practices" at 51CTO College.
4. Is there a good authentication mechanism?
A: Public images can be any pull. Apart from Program automatic verification, parse dockerfile to know the source.
5. kernel and software security issues are common and the initiative is beyond the control of docker
A: Yes, so docker's attitude is that I have fixed the quality of my code and often gave myself a health check. However, policy defense is used for image problems.
