A lightweight configuration method for cloud-native traffic detection and protection engines

Abstract

A lightweight cloud-native traffic detection and protection engine configuration method includes creating a first veth device pair within the engine's pod when the engine starts; creating a second veth device pair connecting the business workload pod and a virtual network bridge in the pod's initial state; creating a third veth device pair within the business workload pod's namespace after the pod enters protection mode; and utilizing traffic mirroring technology to match traffic and copy it to the target interface. The method deploys the engine on each node in the cloud-native environment, changing the container's data path. Furthermore, veth and traffic controllers are used to implement serial detection of workloads and pods in the cloud-native environment, and protection is implemented for threatening traffic.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing and network security technologies, and more specifically, to a lightweight cloud-native traffic detection and protection engine configuration method. Background Art

[0002] With the rapid development of information technology, network environments are becoming increasingly complex, and network security threats are constantly evolving. Traditional IDS / IPS devices are mostly hardware-based, and their processing power is gradually becoming a bottleneck in the face of growing network traffic. Furthermore, the relatively fixed configurations and policies of traditional network security devices make them difficult to adapt to the dynamic network architectures of cloud-native environments.

[0003] Cloud-native architectures, with containerization, microservices, continuous delivery, and dynamic orchestration as core features, enable enterprises to build, deploy, and manage applications more efficiently. Container orchestration platforms such as Kubernetes have become critical infrastructure for cloud-native environments, with numerous workloads running in containerized form on cloud platforms. This architecture offers improved resource utilization, faster application deployment, and improved scalability, but it also introduces new security challenges. In cloud-native environments, communication patterns between workloads are more complex and diverse. The frequent creation, destruction, and migration of containers leads to dynamic changes in network topology, making traffic paths unpredictable. Furthermore, microservices architectures split applications into multiple small services, resulting in frequent interactions between services and more dispersed traffic distribution, making traffic detection and management more challenging. For example, a typical microservices application may consist of dozens or even hundreds of microservices, and the communication traffic between each microservice requires effective detection and protection to ensure the security of the entire application.

[0004] Cloud-native environments emphasize efficient resource utilization and rapid response. Therefore, traffic detection and protection engines must be lightweight, enabling real-time detection and protection without consuming excessive system resources. Furthermore, they must possess efficient packet processing capabilities to meet the high-concurrency, low-latency traffic demands of cloud-native environments.

[0005] Therefore, the problems existing in the prior art need to be further improved and developed. Summary of the Invention

[0006] (1) Purpose of the invention: In order to solve the problems existing in the above-mentioned prior art, the purpose of the present invention is to provide a lightweight cloud-native traffic detection and protection engine configuration method, which can realize real-time detection and protection of traffic in a cloud-native environment without occupying too many system resources.

[0007] (II) Technical Solution: To address the above technical issues, this technical solution provides a lightweight cloud-native traffic detection and protection engine configuration method, specifically including:

[0008] Step 1: When the engine starts, create the first veth device pair in the engine's Pod;

[0009] Step 2: In the initial state of the Pod, create a second veth device pair connecting the business workload pod and the virtual bridge;

[0010] Step 3: After the pod enters protection mode, create a third veth device pair in the business workload pod namespace;

[0011] Step 4: Use traffic mirroring technology to match traffic and copy it to the target interface.

[0012] Preferably, the engine in step 1 is deployed in a DaemonSet manner, a Pod exists on each node of the engine, and a first veth device pair is created in the namespace of the engine pod: vth and vbr.

[0013] Preferably, a tc qdisc is set in the ingress direction of the vbr, and the tc qdisc is an ingress qdisc, in order to subsequently attach a tc filter to achieve traffic replication.

[0014] Preferably, the step 3 specifically includes the following steps:

[0015] Step 301: Modify the eth0 interface of the second veth device pair in the business workload Pod namespace to vex- <pid>-eth0, and for the vex- <pid>- Set a temporary MAC address for eth0;

[0016] Step 302: Create a third veth device pair in the business workload Pod namespace: eth1 and vin- <pid>-eth1, and the vex- <pid>-eth0 IP and MAC address are set to the vin- <pid>-eth1;

[0017] Step 303: Move the vex and vin to the network namespace of the container where the engine is located, and set the MAC address of the vex to the new eth0 MAC address. The vex interface and the cni0 interface of the bridge device created by the CNI plug-in form a fourth veth device pair.

[0018] Step 304: Set tc qdisc on the vex interface and the vin interface respectively, and allocate two MAC addresses: ucmac and bcmac according to the index of the vex interface.

[0019] Preferably, the exchange between the original veth interface and the new veth interface of the container Pod is achieved through the steps 301 and 302, thereby exporting the traffic of the container Pod to the engine and achieving isolation of the container Pod.

[0020] Preferably, the tc qdisc set on the vex interface and the vin interface are both ingress qdiscs to achieve traffic replication.

[0021] Preferably, the step 4 specifically includes:

[0022] Step 401: Execute the first tc filter command to process the inbound traffic of the target container.

[0023] Step 402: Execute the second tc filter command to process the outbound traffic of the target container.

[0024] Step 403: Execute the third tc filter command to forward the outbound traffic of the target container to the container, and copy a copy of the unicast traffic to the VBR for subsequent detection.

[0025] Preferably, the first tc filter command includes two commands, CMD-1 and CMD-2. After the commands are executed by CMD-1 and CMD-2, part of the traffic entering the container is directed to the VBR interface of the engine via unicast, and the rest directly enters the container via VIN. The traffic is replicated in a "mirror" manner.

[0026] Preferably, the second tc filter command includes two commands, CMD-3 and CMD-4; CMD-3 corresponds to CMD-1, which is to add a tc filter on the vin interface to mirror the outgoing traffic of the container to vbr and vex respectively; the difference between CMD-3 and CMD-1 is that CMD-3 needs to match whether the source MAC address of the data packet is the MAC address of the container, and after matching, the source MAC address of the data packet is modified through pedit to the ucmac allocated in step 304.

[0027] Preferably, the third tc filter command includes two commands, CMD-5 and CMD-6; the CMD-5 and CMD-6 correspond to the CMD-1 and CMD-3, and the container Pod outbound / inbound traffic mirrored to the vbr is mirrored to vin and vex.

[0028] (III) Beneficial Effects: This invention provides a lightweight method for configuring a cloud-native traffic detection and protection engine. First, the IDS / IPS engine is automatically deployed on each node in the cloud-native environment using DaemonSet. When the workload (container) enters protection mode, the container's data path is changed. Second, the workload and the IDS / IPS Pod in the cloud-native environment are connected in series via veth and traffic controllers, connecting the container to the engine "device." This allows the detection engine to capture traffic from all protected containers on the vth interface. The engine then conducts in-depth analysis and detection of the captured traffic. If it identifies threatening traffic, it can take measures such as blocking to achieve protection. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 This is a schematic diagram of the steps of a lightweight cloud native traffic detection and protection engine configuration method of the present invention;

[0030] Figure 2 It is the state of the network namespace after the engine is initialized;

[0031] Figure 3 It is the veth device pair in the initial state of the workload Pod;

[0032] Figure 4 This is a diagram showing the renaming of the veth interface within the business workload Pod.

[0033] Figure 5 This is a diagram of creating a new veth pair in the business workload Pod namespace;

[0034] Figure 6 This is a diagram of moving the newly created veth pair in the container namespace to the engine namespace;

[0035] Figure 7 This is a diagram of processing the target container's inbound traffic mirroring;

[0036] Figure 8 This is a diagram of processing the outbound traffic mirror of the target container;

[0037] Figure 9 This is a schematic diagram that completes the entire process. DETAILED DESCRIPTION

[0038] The present invention is further described in detail below in conjunction with preferred embodiments. More details are set forth in the following description to facilitate a full understanding of the present invention. However, the present invention can obviously be implemented in a variety of other ways different from the description. Those skilled in the art can make similar generalizations and deductions based on actual application situations without violating the connotation of the present invention. Therefore, the scope of protection of the present invention should not be limited by the content of this specific embodiment.

[0039] The accompanying drawings are schematic diagrams of embodiments of the present invention. It should be noted that the drawings are merely examples and are not drawn to scale, and should not be used to limit the actual scope of protection claimed in the present invention.

[0040] A lightweight cloud native traffic detection and protection engine configuration method, such as Figure 1 As shown, the specific steps include:

[0041] Step 1: When the engine starts, create the first veth device pair in the engine's Pod.

[0042] Step 2: In the initial state of the Pod, create a second veth device pair connecting the business workload pod and the virtual bridge.

[0043] Step 3: After the pod enters guard mode, create a third veth device pair in the business workload pod namespace.

[0044] Step 4: Use traffic mirroring technology to match traffic and copy it to the target interface.

[0045] More specifically, step 1 is as follows: when the engine starts, a first veth device pair is created in the engine's Pod: vth and vbr.

[0046] Preferably, the engine in step 1 is deployed in DaemonSet mode, and there is a Pod on each node of the engine, such as Figure 2 As shown, vth and vbr are the first veth device pair created in the engine's pod namespace. tc qdisc is set on the ingress of the vbr to control traffic queuing in the pod's namespace, thereby achieving precise control and management of network traffic.

[0047] The tc qdisc refers to the queuing rules of the TC subsystem. The ingress qdisc is set in the present invention. Its main purpose is to subsequently hang the tc filter to achieve traffic replication and reproduce the traffic of a certain network card to other network devices. When the data packet enters the network interface, the ingress qdisc will process the data packet. Since the ingress qdisc does not involve the queuing and dequeuing process of the data packet, it mainly controls the data packet through classification (classify) and filtering (filter). The ingress qdisc can add multiple filtering rules (filter), and each filter can perform specific operations on the matching data packets, such as speed limit, marking, redirection, etc.

[0048] The Pod is the smallest deployable unit that can be created and managed in a Kubernetes workload. It is a package of a group of containers that share storage and networking. Within this group of containers, there is a container called Sandbox (or Pause) that holds the namespace shared by this group of containers.

[0049] A namespace is a resource isolation mechanism provided by the Linux kernel. It is used to isolate the running environment of a process, including file system mount points, process IDs, networks, and UTS names. By using a namespace, you can create a process with an independent running environment, making it invisible to other processes and system resources. The relationship between a namespace and a Pod is a "belong" relationship, for example, a Pod belongs to a certain namespace.

[0050] The TC subsystem refers to the Linux Traffic Control (TC) subsystem, which is responsible for policing, classifying, shaping, and scheduling network traffic. It also processes packet content during the classification process by using filters and actions. The TC subsystem is implemented using the tc qdisc queuing discipline.

[0051] The veth device pair is a virtual Ethernet device. Veth devices are always created in the form of an interconnected pair and are often used to act as tunnels between network namespaces, creating a bridge to a network device in another namespace. They can also be used as independent network devices.

[0052] More specifically, step 2 is as follows: in the initial state of the Pod, a second veth device pair connecting the business workload pod and the virtual bridge is created in the CNI plug-in: cni0 and eth0.

[0053] Preferably, in step 2, a second veth device pair is created through the CNI plug-in of Kubernetes: cni0 and eth0, such as Figure 3 As shown, cni0 is the bridge device created by the CNI plug-in on the host machine, and eth0 is the network interface in the workload Pod. The second veth device enables the control plane to finely control the protection mode of a workload Pod.

[0054] The control plane can be understood as the management end, typically implemented as a web application. Because the control plane has collected all workload pods in the monitored cluster, it can communicate with the engine pods deployed in the cluster to inform the engine of the objects that need protection, facilitating precise traffic control.

[0055] The CNI (Container Network Interface) plugin is a key component used by Kubernetes to implement container networking. It defines a standard interface between the container runtime and the network plugin, enabling seamless integration of various networking solutions with Kubernetes, providing network connectivity and communication capabilities for containers. In a Kubernetes cluster, the CNI plugin is responsible for creating and configuring network resources for pods, including the crucial operation of creating veth device pairs.

[0056] Preferably, the step 3 is specifically as follows: after the Pod enters the protection mode, a third veth device pair is created in the business workload pod namespace: eth1 and vin; the IP and mac addresses of the interface eth0 of the second veth device pair are set to the eth1 interface of the third veth device pair, and the traffic is directed to the vbr interface of the first veth device pair of the engine to isolate the Pod.

[0057] More specifically, step 3 includes the following steps:

[0058] Step 301: Figure 4 As shown, change the eth0 interface of the second veth device pair in the business workload Pod namespace to vex- <pid>-eth0, abbreviated as vex. And for the vex- <pid>- Set a temporary MAC address for eth0.

[0059] Step 302: Figure 5 As shown, create a third veth device pair in the business workload Pod namespace: eth1 and vin- <pid>-eth1, the vin- <pid>-eth1 is abbreviated as vin. <pid>-eth0 IP and MAC address are set to the vin- <pid>-eth1.

[0060] The eth1 interface of the third veth device pair remains in the target container Pod namespace, while the original eth0 interface of the target container becomes vex and moves to the engine container. At this time, the target container Pod is isolated from the outside world. Because the detection engine will create a new veth device pair, one end is eth1, this new eth1 is placed in the business workload Pod namespace, and the other end remains in the engine namespace, called vin-eth1; the original eth0 of the container is moved to the namespace where the engine is located and becomes vex- <pid>-eth0. In this way, the engine can implement the tc traffic diversion policy for vin and vex in its own namespace, so that the target container and the external traffic are connected in series on the engine device. In other words, if the container is accessed from the outside at this time, the traffic will not be perceived by the application in the container. Similarly, the container cannot access external services.

[0061] More specifically, pid represents the unique identifier assigned by the engine to the container Pod.

[0062] like Figure 6 As shown, through the steps 301 and 302, the original veth interface and the new veth interface of the container Pod can be exchanged, thereby exporting the traffic of the container Pod to the engine and isolating the container Pod.

[0063] Step 303: Move the vex and vin to the network namespace of the container where the engine is located, and set the MAC address of the vex to the new eth0 MAC address. The vex interface and the cni0 interface of the bridge device created by the CNI plug-in form a fourth veth device pair.

[0064] At this time the vex- <pid>-The temporary MAC address of eth0 is no longer used.

[0065] Step 304: Set up tc qdisc on the vex interface and the vin interface respectively to prepare for the subsequent addition of tcfilter. At the same time, allocate two MAC addresses: ucmac and bcmac according to the index of the vex interface.

[0066] By adding the tc filter, traffic from the business workload container Pod can be "serialized" to the engine's VBR, thereby protecting the engine. The tc qdiscs configured on the vex and vin interfaces are both ingress qdiscs, enabling traffic replication. When packets enter the network interface, the ingress qdisc processes them. The ingress qdisc can have multiple filters added to it, each of which can perform specific actions on matching packets, such as rate limiting, marking, and redirection.

[0067] The ucmac and bcmac addresses are mainly used to identify the Pod.

[0068] In the preferred embodiment of the present invention, step 4 specifically includes: using traffic mirroring technology to match traffic and then copy the traffic to the target interface, so that the traffic can be circulated again within the Pod. It should be noted that the traffic replication is in the form of "copy mirror" rather than "move redirect".

[0069] More specifically, step 4 includes the following steps:

[0070] Step 401: Execute the first tc filter command to process the inbound traffic of the target container.

[0071] The first tc filter command includes two commands, CMD-1 and CMD-2. CMD-1 is tc filter add dev vex … protocol ip u32 match u8 0 1 at -14 match … action pedit … pipe action mirred egress mirror dev vbr . CMD-1 as a whole describes "copying unicast traffic destined for the container's MAC address to the vbr interface." CMD-2 is tc filter add dev vex …protocol all u32 match u8 0 0 action mirred egress mirror dev vbr vin . The "match u8 0 0" in CMD-2 indicates identity, meaning that all remaining traffic not matched in CMD-1 is copied to vin.

[0072] After the CMD-1 and CMD-2 commands are executed, part of the traffic entering the container is directed to the engine's vbr interface via unicast, and the rest directly enters the container via vin. Figure 7 shown.

[0073] The inbound traffic path for a container is the traffic from the host machine to the container. The container is the business workload container Pod, which is the protected object. The host machine is used to host the container and provide the container runtime environment. It can be a virtual machine or a physical machine, without specific restrictions.

[0074] CMD-1 and CMD-2 omit many command line details through the symbol "...". Both commands add two filters to the ingress of the vex interface. Any packet entering the device's tc subsystem is classified. A filter is a classification method used to determine the class into which the packet is placed. In this invention, only the u32 classifier is used. "match u8 0 1 at -14 match" in CMD-1 indicates "binary ANDing the least significant bit of the first node of the MAC address with 1, then comparing it with 0." If the result is 0, it indicates unicast traffic. The following "match .." in "14match" checks whether the packet's destination MAC address is the container's MAC address. If a match is found, two actions are executed. The first, "action pedit," modifies the packet (the omitted details indicate "changing the packet's destination MAC address to the ucmac assigned in step 304"). The second, "action mirred," mirrors the traffic to the vbr interface.

[0075] Step 402: Execute the second tc filter command to process the outbound traffic of the target container.

[0076] The second tc filter command includes two commands, CMD-3 and CMD-4. The CMD-3 is tc filteradd dev vin … u32 match u8 0 1 at -14 match … action pedit … pipe action mirred egress mirror dev vbr. The CMD-3 corresponds to CMD-1 and adds a tc filter on the vin interface to mirror the container's outbound traffic to vbr and vex respectively. The difference between the CMD-3 and CMD-1 is that CMD-3 needs to match the source MAC address of the data packet to see if it is the MAC address of the container. After matching, the source MAC address of the data packet is modified through pedit to the ucmac assigned in step 304. The CMD-4 is tc filter add dev vin … u32 match u8 0 0action mirred egress mirror dev vbr vex.

[0077] The CMD-3 and CMD-4 add two filters in the inlet direction of the vin interface respectively. Finally, the effect achieved by the CMD-3 and CMD-4 is as follows Figure 8 shown.

[0078] Step 403: Execute the third tc filter command to forward the outbound traffic of the target container to the container, and copy a copy of the unicast traffic to the VBR for subsequent detection.

[0079] The third tc filter command includes two commands, CMD-5 and CMD-6. CMD-5 is tc filter adddev vbr ... u32 match ... action pedit ... pipe action mirred egress mirrordev vin. CMD-6 is tc filter add dev vbr ... u32 match ... action pedit ... pipe action mirred egress mirror dev vex.

[0080] The CMD-5 and CMD-6 correspond to the CMD-1 and CMD-3. Their main purpose is to mirror the inbound / outbound traffic of the container Pod mirrored to the vbr to vin and vex. The omitted details of "u32 match" indicate "whether the MAC address is ucmac", and the omitted details of "action pedit" indicate modifying the source / destination MAC address of the data packet to the MAC address of the container. Finally, the effects achieved by CMD-5 and CMD-6 are as follows: Figure 9 As shown in the figure, the engine uses the veth device pair and the tc traffic mirroring function to cleverly "connect" the Pod's traffic to the engine's vbr-vth device pair, thereby realizing traffic detection and blocking.

[0081] According to the IPv4 protocol, IPv4 addresses are classified into three types: unicast, multicast, and broadcast. Unicast traffic refers to traffic with a unicast destination address in IP. Unicast is a point-to-point connection between a client and a server. Point-to-point means that each client receives a remote stream from the server. Unicast streams are only sent when a client requests them.

[0082] After step 4, the isolation state of the container Pod in step 3 is released, and communication between the outside world and the business workload Pod can proceed normally.

[0083] It should be noted that in Figure 2-Figure 9 In the figure, double arrows represent veth device pair connections; long dashed lines represent the data paths of traffic or data packets flowing into the network; and long and short dashed lines represent the data paths of traffic or data packets flowing out of the network.

[0084] This paper describes a lightweight cloud-native traffic detection and protection engine configuration method. First, the IDS / IPS engine is automatically deployed on each node in the cloud-native environment using DaemonSet. When the workload (container) enters protection mode, the container's data path is altered. Second, the workload in the cloud-native environment is connected in series with the IDS / IPS Pod using veth and tc, connecting the container to the engine "device." This allows the detection engine to capture traffic from all protected containers on the vth interface. The engine then performs in-depth analysis and detection of captured traffic. If any threatening traffic is detected, it can take measures such as blocking to achieve protection.

[0085] The above content is an explanation of the preferred embodiments of the present invention, which can help those skilled in the art to more fully understand the technical solutions of the present invention. However, these embodiments are merely illustrative, and it cannot be determined that the specific implementation methods of the present invention are limited to the description of these embodiments. For those skilled in the art of the present invention, without departing from the concept of the present invention, several simple deductions and transformations can be made, which should be deemed to fall within the scope of protection of the present invention.< / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid> < / pid>

Claims

1. A lightweight cloud native traffic detection and protection engine configuration method, characterized in that: Specifically include: Step 1: When the engine starts, create the first veth device pair in the engine's Pod; Step 2: In the initial state of the Pod, create a second veth device pair connecting the business workload pod and the virtual bridge; Step 3: After the Pod enters protection mode, a third veth device pair is created in the business workload pod namespace. Step 3 specifically includes: Step 301: Modify the eth0 interface of the second veth device pair in the business workload Pod namespace to vex- <pid>-eth0, the vex- <pid>-eth0 is abbreviated as vex interface, and is the vex- <pid> - Set a temporary MAC address for eth0;< / pid> < / pid> < / pid> Step 302: Create a third veth device pair in the business workload Pod namespace: eth1 and vin- <pid>-eth1, the vin- <pid>-eth1 is abbreviated as vin interface, which is the vex- <pid>-eth0 IP and MAC address are set to the vin- <pid> -eth1;< / pid> < / pid> < / pid> < / pid> Step 303: Move the vex interface and the vin interface to the network namespace of the container where the engine is located, and set the MAC address of the vex interface to the MAC address of the eth0 interface of the second veth device pair. The vex interface and the cni0 interface of the bridge device created by the CNI plug-in form a fourth veth device pair. Step 304: Set tc qdisc on the vex interface and vin interface respectively, and allocate two MAC addresses: ucmac and bcmac according to the index of the vex interface; Step 4: Using traffic mirroring technology, after matching the traffic, copy the traffic to the target interface. Step 4 specifically includes: Step 401: Execute the first tc filter command to process the inbound traffic of the target container. Step 402: Execute the second tc filter command to process the outbound traffic of the target container. Step 403: Execute the third tc filter command to forward the outbound traffic of the target container to the container, and copy a copy of the unicast traffic to the VBR for subsequent detection.

2. According to claim 1, a lightweight cloud native traffic detection and protection engine configuration method is characterized in that: The engine in step 1 is deployed in DaemonSet mode. A Pod exists on each node of the engine. The first veth device pair is created in the namespace of the engine pod: vth and vbr.

3. A lightweight cloud native traffic detection and protection engine configuration method according to claim 2, characterized in that: A tc qdisc is set at the ingress direction of the vbr. The tc qdisc is an ingress qdisc for subsequent tcfilter installation to achieve traffic replication.

4. According to claim 1, a lightweight cloud native traffic detection and protection engine configuration method is characterized in that: Through step 301 and step 302, the original veth interface and the new veth interface of the container Pod are exchanged, thereby exporting the traffic of the container Pod to the engine and isolating the container Pod.

5. A lightweight cloud native traffic detection and protection engine configuration method according to claim 4, characterized in that: The tc qdiscs set on the vex interface and the vin interface are both ingress qdiscs, which implement traffic replication.

6. A lightweight cloud native traffic detection and protection engine configuration method according to claim 1, characterized in that: The first tc filter command includes two commands, CMD-1 and CMD-2. After the commands are executed by CMD-1 and CMD-2, part of the traffic entering the container is directed to the engine's VBR interface via unicast, and the rest directly enters the container through VIN. The traffic is replicated in the form of "mirror replication".

7. A lightweight cloud native traffic detection and protection engine configuration method according to claim 1, characterized in that: The second tc filter command includes two commands, CMD-3 and CMD-4. CMD-3 corresponds to CMD-1 and adds a tc filter on the vin interface to mirror the outbound traffic of the container to vbr and vex respectively. The difference between CMD-3 and CMD-1 is that CMD-3 needs to match the source MAC address of the data packet to see if it is the MAC address of the container. After matching, the source MAC address of the data packet is modified through pedit to be the ucmac assigned in step 304.

8. A lightweight cloud native traffic detection and protection engine configuration method according to claim 1, characterized in that: The third tc filter command includes two commands, CMD-5 and CMD-6. The CMD-5 and CMD-6 correspond to CMD-1 and CMD-3, and the inbound / outbound traffic of the container Pod mirrored to the vbr is then mirrored to the vin interface and vex interface.

Images