The Birth of Cloud Native
In 2013, Matt Stine of Pivotal first proposed the concept of Cloud Native. With the passage of time, the current concept of cloud native can be summarized into four main points: microservices, containerization, DevOPS, and continuous delivery .
Cloud-native is bound to the cloud environment during project development. For cloud-native security, it is necessary to simultaneously consider cloud application security when creating a cloud environment, so that application security issues can be shifted to the left and security issues should be front-loaded.
If the application uses a cloud-native architecture, traditional software security issues will not disappear, but will cause more problems due to the complexity of the cloud architecture and the increase in direct component calls. The construction of the cloud-native security protection system should be built around the life cycle of cloud-native applications. The entire life cycle is divided into construction-distribution-operation, involving development security, image security, container security, host machine security, application security, and container orchestration platform Security, which is also the application security model advocated by DevSecOps in agile development.
Before talking about cloud-native security, let's take a look at the four main points of cloud-native.
01 Microservices
Before understanding microservices, let’s first understand what is a monolithic application. As early as when MVC (Spring + iBatis/Hibernate + Tomcat) was the mainstream technology stack, the concept of monolithic application was born, because the MVC architecture is designed for monolithic applications. Yes, the developer will start and load the written WAR package through tomcat to provide external services. The MVC architecture is suitable for scenarios where the business scale is small and the development team is small.
However, with the continuous development of IT, more and more businesses are carried by digital projects, and the disadvantages of single application appear. For example, when the development team collaborates with multiple people, the code is submitted and packaged and deployed together for testing. Once there is a function in the testing phase If there is a problem with the module, it must be recompiled, packaged, deployed, and then tested. All relevant developers have to participate in it, resulting in increased development costs, low development efficiency, and low deployment efficiency.
The traditional MVC architecture deploys all functions in the same war package and runs in the same tomcat container, which will destroy everything at once, resulting in the unavailability of all services in the JVM process.
Based on the above, microservices came into being .
In 2014, the maturity of containerization technology represented by Docker and the rise of DevOps culture slowly evolved into the microservices we are familiar with today.
Features of microservices: Services are deployed independently. For example, a physical machine can deploy multiple Docker instances, which can be subdivided into a sub-module, and can independently form a microservice and be maintained independently.
Microservices can run in their "own program". In the microservice architecture, only the required functions need to be added to specific services without affecting the overall process architecture. With the continuous expansion of the scale of the mobile Internet, the development and practice of agile development, continuous delivery, and DevOps theory, and the gradual maturity of Docker-based containerization technology, the microservice architecture has become popular and has gradually become the future evolution direction of the application architecture.
02 Containerization
When it comes to containerization, let’s start with docker. Docker is an open source containerization platform. The feature of Docker is “one-time creation or configuration, and it can run normally anywhere.” That is, the software is installed with the environment, and the original environment is exactly copied during installation. One copy will eliminate the problem of different running results of different machines.
The basic components of Docker include: container, image, warehouse
Mirroring : Mirroring is implemented based on layers. As a read-only template, files can be added and deleted at each layer.
Mirroring can create docker containers, and multiple containers can be created.
Container : It can be understood as an application that docker uses containers to run independently. The running instance created by the image is the container. The relationship between the container and the image: the image is responsible for storage and distribution, and the container is responsible for running, just like classes and instances in Java, specific objects can be instantiated through classes, and methods in the class can be called through specific objects.
Warehouse : In docker, a warehouse is a place where images are stored in a centralized manner. It is a centralized storage and distribution service for images. Each warehouse can contain multiple tags, and each tag corresponds to an image. Usually, a warehouse will contain images of different versions of the same software, and tags are often used to correspond to each version of the software.
There are many advantages of Docker. Compared with virtual machines, Docker containers are as follows:
Universities use system resources, faster startup time, consistent operating environment, devops continuous delivery, continuous deployment, low coupling, and easier maintenance and expansion.
03 Devops
DevOps includes development and operations, which is the general term for development and operation and maintenance. In order to consolidate the results of software design and development, development, operation and maintenance and testing are combined to form a DevOps software development management model.
04 Continuous delivery
It is difficult to frequently release new functions to users without affecting users' use of services. It is difficult to achieve this in traditional development and delivery. Frequent releases and online releases will have different degrees of impact on different users. Now the mainstream cloud native technology can achieve continuous delivery without affecting the use of users through microservices + containerization + devops.
Based on cloud native principles
Build cloud-native secure RASP applications
Cloud native refers to the combination of various improvement technologies and efficiency based on the cloud, getting rid of physical storage, and realizing application professional optimization and efficiency improvement. After understanding the principles of cloud native, we can look back at cloud native security to know our focus. Cloud native security can include software development security, image security, host security, and software runtime security.
The open source network security application security protection platform (RASP) uses stub technology to realize attack detection and protection without manual intervention and without perception. For Internet enterprises and distributed application projects, the deployment efficiency and protection effect of the RASP platform are more obvious.
Security application of RASP in cloud-native scenarios:
The main function of RASP is the security protection of the application runtime. In addition to the vulnerability detection, application hardening, 0day defense, security weakness protection, and security baseline detection of the application runtime shown in the above figure, RASP has many other functions.
This is the end of the sharing of this issue. Welcome everyone to enter the open source network security public account, click the menu bar - product service - RASP to try the open source network security RASP platform.