Chips VS Threats of Containerization Technology
The use of containers for developing and deploying software has long become standard practice. The ability to easily provide the program with a standard environment, independent of the host on which it is running, to quickly change settings, add or change some components in the container, was appreciated by many developers. But this is only a small part of all the chips that are provided by the containerization technology.
As always, the development of technology and the growth of its popularity are accompanied by the identification of various ways of non-standard use, including malicious. In this article we will also look at the security risks of the development process associated with the use of containers, and talk about why the DevOps processes should be transformed into DevSecOps.
Let's start with why containers win the sympathies of developers and how the use of containerization changes the development as a whole.
Lightness
Compared to virtual machines and “iron” servers, containers are completely undemanding of resources. This allows you to run significantly more containers on one machine than virtual machines. A developer can even run application components on his computer in the form of containerized microservices and he will not have to nap while waiting for the system to respond. Due to the fact that the containers share the core of the system, they are started and stopped much faster than restarting the virtual machine.
Insulation
Despite the sharing of the kernel, the application in the container runs in isolation from other parts of the system and applications. This means that an error in the application will only affect a specific container.
The use of containers in the development allows you to get away from the eternal conflict of developers and system administrators about the privileges. The container safely separates the application from the system, so the programmer can afford any experiments without fear of destroying the OS.
Portability
Each application runs in its own container instance with its own configuration files. This eliminates the headache associated with moving an application between hosts: everything you need to work is stored inside the container and transferred along with the rest of the application components.
Container repositories
The emergence of the standard Open Container Initiative has led to the fact that it has become possible to create public libraries of container images and form a powerful ecosystem that combines container engines, cloud platforms and tools for container management, security checks and other tasks.
Automation
The use of containers allows you to build fully automated chains of continuous integration and deployment of applications (CI / CD), in which the “manual” part will be mainly writing code. Testing, checking the quality of the code, packaging the application in a Docker image, placing the image on the Docker Hub and deploying it to the host for execution can be performed without human intervention.
Of course, with all their advantages, containers have various disadvantages. These are, for example, performance problems with resource-intensive applications and limited portability of images built for different architectures. But in addition to technological problems, containers have security problems.
Kernel sharing
As always, disadvantages are the reverse side of the advantages. Kernel sharing reduces container redundancy compared to virtual machines, but the greater the number of allowed syscalls makes the security barrier more subtle, and the exploitation of kernel vulnerabilities allows you to attack all containers at once. This brings to mind the Specter and Meltdown sensational attacks, which allow you to read the memory of someone else's process or kernel from user-space.
Public Repositories
The presence of public registries with images gives a rich choice of "wrappers" for containers, but creates additional threats, since by default the registry server is trusted. If attackers succeed in modifying the base images with malicious libraries, the changes will automatically spread across all the servers in which this base image is stored in the cache, and all containers that use the library will automatically acquire malicious functionality.
Thus, one malicious library is enough to compromise the application. Of course, vulnerabilities and malicious functions in popular libraries are not a problem of containers as such, but of technology that ensures the rapid spread of changes in images.
Obviously, the current development process requires a new approach, an approach in which security will be integrated into the CI / CD chain, turning DevOps into DevSecOps.
According to Gartner, in 2019
Consider some of the components that must be present in the process so that the word “Sec” in its name is not an empty sound.
Integration of checks into all processes
Security checks must be present at all stages of the development process, from code generation to containerization and deployment.
Automate security checks
Required for two reasons:
API for security functions
Implementing such functionality requires the security system to provide an API for accessing all features. So developers can not only use the system to check, but also embed the appropriate calls in the code.
Role-based access control
Different security specialists need different levels of access to the verification mechanisms, depending on their role, since it is necessary that developers do not have the opportunity to change security settings, but they are not responsible for penetrating threats.
Compatible with Docker Registry API
Ideally, protection should support Docker image scans in any registry that supports the Docker Registry V2 API to ensure compatibility with all popular registries.
Migration Protection
For corporate users, the dangerous moment is the transition from monolithic to microservice architecture. It is important that the security features are built into the integration processes, providing protection in automatic mode.
An example of a security solution is the Trend Micro Deep Security Smart Check, which continuously scans images in automatic mode, detects vulnerabilities and malware. Smart Check supports Docker Trusted Registry, Amazon Elastic Container Registry, Azure Container Registry and Google Container Registry container platforms. In addition, Trend Micro integrates with leading SIEM systems and such orchestration tools as Jenkins, Kubernetes, SumoLogic, Splunk.
An important feature of Smart Check is compliance with all requirements of regulators in terms of checking critical vulnerabilities and event logging.
Embedding container security into DevOps processes in the early stages of development before launching applications will allow developing more reliable and productive software, as well as
As always, the development of technology and the growth of its popularity are accompanied by the identification of various ways of non-standard use, including malicious. In this article we will also look at the security risks of the development process associated with the use of containers, and talk about why the DevOps processes should be transformed into DevSecOps.
Let's start with why containers win the sympathies of developers and how the use of containerization changes the development as a whole.
Chips
Lightness
Compared to virtual machines and “iron” servers, containers are completely undemanding of resources. This allows you to run significantly more containers on one machine than virtual machines. A developer can even run application components on his computer in the form of containerized microservices and he will not have to nap while waiting for the system to respond. Due to the fact that the containers share the core of the system, they are started and stopped much faster than restarting the virtual machine.
Insulation
Despite the sharing of the kernel, the application in the container runs in isolation from other parts of the system and applications. This means that an error in the application will only affect a specific container.
The use of containers in the development allows you to get away from the eternal conflict of developers and system administrators about the privileges. The container safely separates the application from the system, so the programmer can afford any experiments without fear of destroying the OS.
Portability
Each application runs in its own container instance with its own configuration files. This eliminates the headache associated with moving an application between hosts: everything you need to work is stored inside the container and transferred along with the rest of the application components.
Container repositories
The emergence of the standard Open Container Initiative has led to the fact that it has become possible to create public libraries of container images and form a powerful ecosystem that combines container engines, cloud platforms and tools for container management, security checks and other tasks.
Automation
The use of containers allows you to build fully automated chains of continuous integration and deployment of applications (CI / CD), in which the “manual” part will be mainly writing code. Testing, checking the quality of the code, packaging the application in a Docker image, placing the image on the Docker Hub and deploying it to the host for execution can be performed without human intervention.
Container Threats
Of course, with all their advantages, containers have various disadvantages. These are, for example, performance problems with resource-intensive applications and limited portability of images built for different architectures. But in addition to technological problems, containers have security problems.
Kernel sharing
As always, disadvantages are the reverse side of the advantages. Kernel sharing reduces container redundancy compared to virtual machines, but the greater the number of allowed syscalls makes the security barrier more subtle, and the exploitation of kernel vulnerabilities allows you to attack all containers at once. This brings to mind the Specter and Meltdown sensational attacks, which allow you to read the memory of someone else's process or kernel from user-space.
Public Repositories
The presence of public registries with images gives a rich choice of "wrappers" for containers, but creates additional threats, since by default the registry server is trusted. If attackers succeed in modifying the base images with malicious libraries, the changes will automatically spread across all the servers in which this base image is stored in the cache, and all containers that use the library will automatically acquire malicious functionality.
Examples
- In June 2018, 17 containers with malicious code were removed from the Docker Hub portal , but before that, within a few months, they had been downloaded more than a million times.
- In September 2018, an example of an attack on Python installation packages was published on GitHub , during which the setup.py file was modified to run malicious code when the package was installed. Since, as a rule, this file is used only for adding a module, very few people check its contents .
- In October 2018, information about 12 malicious libraries uploaded to the PyPi catalog was published . The libraries contained code for collecting data, maintaining presence on the infected host, launching a reverse shell, and spoofing addresses of Bitcoin wallets with the address of the attacker .
- In November 2018, a malicious code was discovered in one of the dependencies of the Event-Stream library used in many large projects , designed to steal cryptocurrency and launch attacks against virtual services related services. Event-Stream is a popular library, the number of daily downloads from the NPM repository totals about 2 million.
- In January 2019, a critical vulnerability was reported in the pickle module of the popular NumPy Python library , using which you can get remote code execution.
Thus, one malicious library is enough to compromise the application. Of course, vulnerabilities and malicious functions in popular libraries are not a problem of containers as such, but of technology that ensures the rapid spread of changes in images.
Recommendations
Obviously, the current development process requires a new approach, an approach in which security will be integrated into the CI / CD chain, turning DevOps into DevSecOps.
According to Gartner, in 2019
- More than 70% of corporate development processes will contain automated checks for vulnerabilities and configurations of open-source components and commercial packages.
- more than 50% of the CI / CD processes will contain mandatory built-in code security checks;
- more than 60% of companies will use in the development of version control tools and infrastructure automation management
Consider some of the components that must be present in the process so that the word “Sec” in its name is not an empty sound.
Integration of checks into all processes
Security checks must be present at all stages of the development process, from code generation to containerization and deployment.
Automate security checks
Required for two reasons:
- This will reduce the number of administration errors and misconfiguration.
- Security professionals will not have to manually check the code and change the settings.
API for security functions
Implementing such functionality requires the security system to provide an API for accessing all features. So developers can not only use the system to check, but also embed the appropriate calls in the code.
Role-based access control
Different security specialists need different levels of access to the verification mechanisms, depending on their role, since it is necessary that developers do not have the opportunity to change security settings, but they are not responsible for penetrating threats.
Compatible with Docker Registry API
Ideally, protection should support Docker image scans in any registry that supports the Docker Registry V2 API to ensure compatibility with all popular registries.
Migration Protection
For corporate users, the dangerous moment is the transition from monolithic to microservice architecture. It is important that the security features are built into the integration processes, providing protection in automatic mode.
An example of a security solution is the Trend Micro Deep Security Smart Check, which continuously scans images in automatic mode, detects vulnerabilities and malware. Smart Check supports Docker Trusted Registry, Amazon Elastic Container Registry, Azure Container Registry and Google Container Registry container platforms. In addition, Trend Micro integrates with leading SIEM systems and such orchestration tools as Jenkins, Kubernetes, SumoLogic, Splunk.
An important feature of Smart Check is compliance with all requirements of regulators in terms of checking critical vulnerabilities and event logging.
Embedding container security into DevOps processes in the early stages of development before launching applications will allow developing more reliable and productive software, as well as
- Detect malware and libraries.
- Identify vulnerabilities.
- Correct errors before images are transferred to orchestration tools (for example, Kubernetes).
- Prevent the execution of malicious code and the deployment of vulnerable software.
Source: https://habr.com/ru/post/439986/