A brief discussion on enterprise security and the security risks under cloud-native

Preface

I have read some knowledge about DevOps before, and many articles have mentioned cloud-native. But I have always been confused about cloud-native, so I wrote this article.

Due to my limited abilities, there may be some errors in the article. I welcome corrections from everyone and I am grateful. If you have any good ideas, please feel free to communicate~~

What is cloud-native security?

Now cloud-native is very popular, it seems that if you don't understand cloud-native, you are really out of date. Everyone can say a few words about cloud-native, but if you ask them for a clear definition of cloud-native, most people may not be able to come up with an answer. This is because cloud-native does not have a clear definition in itself, and its definition is constantly changing over time.

On the surface, cloud-native (CloudNative) includes two aspects: cloud and native. Cloud is easy to understand, indicating that the application is on the cloud, then what does native refer to?

Cloud: means that the application is located in the cloud rather than the traditional data center.

Native: means that the application is designed to run in the cloud from the very beginning, designed for the cloud, running in the cloud in the best posture, making full use of and giving full play to the elastic and distributed advantages of the cloud platform.

Cloud-native is a method of building and running applications, as well as a set of technology systems and methodologies.

In summary, applications that comply with cloud-native architecture should: adopt open-source stacks (K8S+Docker) for containerization, base on microservices architecture to improve flexibility and maintainability, leverage agile methods and DevOps support for continuous iteration and operation automation, and utilize cloud platform facilities to achieve elastic scaling, dynamic scheduling, and optimize resource utilization.

Cloud-native is also constantly evolving, and its definition may vary at different stages.In a word, cloud-native is a type of technology architecture that emerged to adapt to the cloud environment, making full use of the cloud environment for elastic expansion and contraction (it is not necessarily about k8s+docker).

Cloud-native vs. DevOps

Cloud-native is often mentioned together with DevOps. So, what is the difference between the two?

DevOps is a development philosophy that emphasizes rapid integration and deployment.DevOps does not emphasize the necessity of using cloud and containers. Cloud-native is always associated with the cloud and containers.

Key Technologies of Cloud Native

Representative technologies of cloud-native include containers, service mesh (Service Mesh), microservices, immutable infrastructure, and declarative API.

ContainerContainers enable application services to be separated from the underlying architecture, achieving complete portability (the ability to run applications on any operating system or environment), and when an application consists of many independent components, a container can also be assigned to each component. It provides strong support for rapid deployment. The representative of containers is docker.

Service MeshService mesh is designed to ensure rapid, reliable, and secure communication between services. Service mesh provides functions such as service discovery, load balancing, encryption, authentication, authorization, circuit breaker pattern (Circuit Breaker Pattern), and a series of other features.

MicroservicesUnder cloud-native, it can be said that microservices architecture is adopted, which was born to solve the disadvantages of traditional monolithic applications. Under the microservices architecture, each microservice runs through an independent process, and microservices communicate with each other through lightweight communication mechanisms, such as RESTful API. Microservices architecture emphasizes that each microservice focuses on a specific business, and is related to specific business scenarios, so the development team can quickly respond to changes in business scenarios (such as changes in business logic) through microservices. In addition, each microservice can be independently developed and deployed, and can be flexibly expanded, which can effectively respond to changes in business volume.

Immutable InfrastructureImmutable infrastructure is different from traditional operations and maintenance, where servers are never modified after deployment. If any updates are needed, such as version upgrades or parameter configuration, new servers need to be built to replace the old servers. In immutable infrastructure, the construction of servers is usually provided in the form of images (Images), and any change corresponds to an image. This concept may be difficult to understand, I think it is the environment on which the service depends packaged into an integrated whole, which generally does not change, and is directly used through this whole when deploying applications.

Declarative APIAPI is generally divided into two types: declarative API and imperative API. The imperative API provides each operation step, and the target system only needs to execute according to the steps, and the target system returns the results to the caller, who processes the results; declarative API provides a final state, and the target system operates on resources to reach the required state, without the caller's intervention. The advantage of declarative API lies in making the delivery between distributed systems simple. We do not need to concern about any process details. The declarative approach can greatly reduce the workload of users and greatly increase the development efficiency, because declarative can simplify the required code, reduce the workload of developers, and if we use the imperative approach for development, although it is more flexible in configuration, it brings more work.

Security analysis under cloud-native

Above, we have learned about the key technologies of cloud-native. Compared with traditional security, the introduction of these technologies also brings new security risks. They can be roughly divided into the following categories:

1) Container security/image security

2) Orchestration tool security

3) Microservice security

4) Service mesh security

Container security/image security

Container technology

Containers are a lightweight virtualization method that packages the application and the necessary execution environment into a container image, allowing the application to run relatively independently on the host (physical machine or virtual machine).

Virtual machines usually include the entire operating system and applications, running a real operating system inside. Essentially, virtual machines are hardware virtualized by Hypervisor, installing different operating systems, while containers are different processes running on the host machine. From the perspective of user experience, virtual machines are heavy-weight, occupy a lot of physical resources, and take a long time to start. Containers, on the other hand, occupy fewer physical resources and start quickly. In relative terms, virtual machines are more thoroughly isolated, while containers are less so.

Containers are built on two key technologies: Linux Namespace and Linux Cgroups.

Namespace

Namespace creates a nearly isolated user space and provides system resources (file system, network stack, processes, and user IDs) for applications. Currently, it is roughly divided into the following 6 types of isolation mechanisms:

·PID Namespace: Different containers are isolated by the pid namespace, and the same pid can exist in different namespaces.
·Mount Namespace: Mount allows processes in different namespaces to see different file structures, therefore, the file directories seen by processes in different namespaces are isolated. In addition, the information in /proc/mounts for each namespace container only contains the current mount points.
·IPC Namespace: Interprocess communication (IPC) in containers still uses the Linux common process interaction methods, including semaphores, message queues, and shared memory, etc.
·Network Namespace: Network isolation is achieved through Net, each Net has independent network devices, IP addresses, routing tables, and /proc/net directory. This allows the network of each container to be isolated.
·UTS Namespace: UTS (UNIX Time-sharing System)