An abnormal traffic governance method and device, a service mesh, and a computing device

Abstract

Embodiments of the present application provide an abnormal traffic governance method and device, a service mesh and a computing device. The method comprises: obtaining a path of traffic generated by a request in a service mesh; the service mesh comprises a plurality of service instances, and the path indicates a data transmission sequence of the traffic generated by the request between the service instances; comparing the obtained path of the traffic with paths in an attack source database; in the case where the obtained path of the traffic matches a path in the attack source database, marking the obtained traffic as abnormal traffic; determining an abnormal injection point according to a matching result, the abnormal injection point being used to represent an abnormal path node in the path of the traffic generated by the request; creating a virtual service instance based on the abnormal injection point; and directing the abnormal traffic to the virtual service instance. Thus, an abnormal traffic defense and isolation mechanism is introduced on the basis of a service mesh architecture, which can prevent abnormal traffic from spreading and ensure that normal business traffic is not affected.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network security, and particularly relates to an abnormal traffic management method and device, a service mesh and a computing device. BACKGROUND

[0002] In a modern network environment, a service mesh is widely used in an infrastructure layer for communication between cluster services, and realizes traffic control and management between services through a lightweight and high-performance mesh proxy. However, with the continuous upgrading of network attack means, the service mesh exposes certain vulnerability and security risks when coping with large-scale traffic attacks, including DDoS attacks, network layer attacks, application layer attacks and other malicious traffic forms, which pose a threat to the normal operation of the service mesh.

[0003] Therefore, it is crucial to provide an abnormal traffic management method. SUMMARY

[0004] Embodiments of the present application provide an abnormal traffic management method, device, service mesh and computing device, which introduces an abnormal traffic defense and isolation mechanism on the basis of a service mesh architecture, and can prevent abnormal traffic from spreading and ensure that normal business traffic is not affected.

[0005] In a first aspect, an abnormal traffic management method is provided, a path of traffic generated by a request in a service mesh is acquired; the service mesh includes a plurality of service instances, and the path indicates a data transmission order of the traffic generated by the request between the service instances; the acquired path of the traffic is compared with paths in an attack source database; when the acquired path of the traffic matches a path in the attack source database, the acquired traffic is marked as abnormal traffic; an abnormal injection point is determined according to a matching result, the abnormal injection point is used to represent a path node that is abnormal in the path of the traffic generated by the request; a virtual service instance is created based on the abnormal injection point; and the abnormal traffic is introduced into the virtual service instance.

[0006] In this scheme, the path of the request is compared with the paths stored in the attack source database, and an abnormal injection point can be accurately identified. When the actual path matches the path in the database, the subsequent part of the abnormal traffic (i.e., the path after the abnormal injection point) is guided to the newly created virtual service instance for isolation or honeypot processing, so as to avoid affecting normal business traffic. The abnormal traffic defense and isolation mechanism is introduced on the basis of the service mesh architecture, which can prevent abnormal traffic from spreading and ensure that normal business traffic is not affected.

[0007] In a possible implementation, the comparison between the path of the obtained traffic and the path in the attack source database comprises: in a case where the path of the obtained traffic and the path in the attack source database cannot be matched, comparing the path of the obtained traffic with an initial path of the request; and in a case where the path of the obtained traffic and the initial path cannot be matched, marking the traffic as abnormal traffic, and adding the path of the obtained traffic to the attack source database.

[0008] In this scheme, when the obtained path cannot be matched with the path in the attack source database, the actual path is further compared with the initial path of the request. This comparison process can help to confirm whether the traffic is abnormal.

[0009] In a possible implementation, the determining of the abnormal injection point in the path of the traffic according to the matching result comprises: the abnormal injection point is a first path node on an abnormal path obtained by the matching result.

[0010] In this scheme, the abnormal injection point marks the starting position of the attack traffic. From this path node, the subsequent traffic will be marked as abnormal and processed according to a predetermined protection strategy. By locating the abnormal injection point, abnormal traffic can be effectively isolated, and normal business can be protected from attack. The identification of the abnormal injection point can accurately locate the actual source of the attack traffic, that is, which service instance the attacker tries to initiate the attack. After determining the abnormal injection point, only the specific service instance is operated, avoiding interference with the entire service mesh.

[0011] In a possible implementation, the method further comprises: the management component obtaining traffic data information of a path node of a path of traffic generated by a request in the service mesh, the traffic data information comprising an initial path of the request, and any one of traffic source, port information, protocol type of the request, traffic size and traffic timestamp; comparing the traffic data information of the request with traffic data information in an attack source database; and in a case where the traffic data information of the request and the traffic data information in the attack source data match, determining that the traffic generated by the request is abnormal traffic.

[0012] In this scheme, in addition to the comparison of the path of the traffic, the abnormal traffic can be further determined through the comparison of the traffic data information. In combination with the double verification of the path comparison and the traffic data information, the abnormal traffic can be more efficiently and comprehensively identified and isolated, and the security defense capability of the service mesh can be further improved.

[0013] In a possible implementation, the matching of the requested traffic data information with the traffic data information in the attack source database comprises: matching the requested traffic data information with alarm rules in a case where the requested traffic data information does not match the traffic data information in the attack source database, the alarm rules being used to indicate abnormal traffic data information; and adding the requested traffic data information to the attack source database in a case where the requested traffic data information matches at least one of the alarm rules.

[0014] In this solution, in the traffic data information matching, the traffic data information can be matched with the alarm rules in addition to the matching with the attack source database. The alarm rules provide a flexible real-time detection means, and abnormal traffic can still be effectively captured when an attacker changes an attack strategy or disguises an attack. The double matching of the traffic data information and the alarm rules can more accurately identify malicious traffic and respond in a timely manner, and enhance the security protection capability of the entire system.

[0015] In a possible implementation, in the traffic data information matching process, the determination of the abnormal injection point can effectively separate normal traffic and abnormal traffic. For malicious traffic, the system can guide the malicious traffic to a honeypot or an isolated environment for processing, without affecting a real business environment.

[0016] In a possible implementation, the creating of the virtual service instance based on the abnormal injection point comprises: creating a virtual service instance using a mirror file of a service instance corresponding to each path node after the abnormal injection point, each virtual service corresponding to one of the service instances; or creating a virtual service instance using a mirror file of a service instance corresponding to a first path node after the abnormal injection point.

[0017] In this solution, the creating of the virtual service instance based on the abnormal injection point enables the system to quickly respond to an attack and dynamically adjust, and the malicious traffic can be isolated and processed by introducing a virtual service instance (a honeypot instance) into a service mesh, so as to protect an actual business environment. Through the real-time processing and isolation of the abnormal traffic, the spread chain of the attack can be timely blocked, and the influence range of the attack can be reduced.

[0018] In a second aspect, the embodiments of the present application also provide an abnormal traffic management device, comprising a management component, configured to acquire a path of traffic generated by a request in a service mesh; the service mesh comprises a plurality of service instances, and the path indicates a data transmission order of the traffic generated by the request between the service instances; compare the acquired path of the traffic with paths in an attack source database; in a case where the acquired path of the traffic matches a path in the attack source database, mark the traffic as abnormal traffic; determine an abnormal injection point according to a matching result; an application program interface component, configured to create a virtual service instance based on the abnormal injection point; and the attack source database, configured to store the path of the abnormal traffic.

[0019] In a third aspect, the embodiments of the present application also provide a service mesh, comprising: a management component, configured to acquire a path of traffic generated by a request in a service mesh; the service mesh comprises a plurality of service instances, and the path indicates a data transmission order of the traffic generated by the request between the service instances; compare the acquired path of the traffic with paths in an attack source database; in a case where the acquired path of the traffic matches a path in the attack source database, mark the acquired traffic as abnormal traffic; determine an abnormal injection point according to a matching result, the abnormal injection point being used to indicate an abnormal path node in the path of the traffic generated by the request; and direct the abnormal traffic to a virtual service instance; an application program interface component, configured to create a virtual service instance based on the abnormal injection point; the attack source database, configured to store the path of the abnormal traffic; and a plurality of nodes, each node running at least one service instance.

[0020] In a fourth aspect, the embodiments of the present application also provide a computing device. The computing device runs computer program instructions to execute the method provided in the first aspect. The computing device can comprise a processor, which can be coupled with a memory, the memory being used to store a program, and the processor being used to execute the program stored in the memory, when the program stored in the memory is executed, the computing device executes the method provided in the first aspect. The memory can be integrated in a chip or a processor, or can be independent of the chip or the processor. The computing device can be a server.

[0021] It can be understood that the beneficial effects of the second aspect to the fourth aspect described above can be referred to the related description in the first aspect, and will not be described here again. BRIEF DESCRIPTION OF DRAWINGS

[0022] Figure 1 A schematic diagram of a service mesh architecture provided by the embodiments of the present application;

[0023] Figure 2 A schematic diagram of a path of traffic generated by a request in a service mesh provided by the embodiments of the present application;

[0024] Figure 3 is a flowchart of an abnormal traffic governance method provided by an embodiment of the present application;

[0025] Figure 4 is a flowchart of an abnormal traffic governance method provided by an embodiment of the present application;

[0026] Figure 5 is a flowchart of an abnormal traffic governance method provided by an embodiment of the present application;

[0027] Figure 6 is a flowchart of an abnormal traffic governance method provided by an embodiment of the present application;

[0028] Figure 7 is a flowchart of an abnormal traffic governance method provided by an embodiment of the present application;

[0029] Figure 8 is an abnormal traffic governance device provided by an embodiment of the present application;

[0030] Figure 9 is a service mesh provided by an embodiment of the present application;

[0031] Figure 10 is a computing device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0032] The term "and / or" in this document is a description of an association relationship between associated objects, which means that there can be three relationships, for example, A and / or B can represent the three cases of A alone, A and B together, and B alone. The symbol " / " in this document represents an or relationship of associated objects, for example, A / B represents A or B.

[0033] The terms "first" and "second" and the like in the description and claims of this document are used to distinguish different objects, and are not used to describe a specific order of the objects. For example, the first response message and the second response message are used to distinguish different response messages, and are not used to describe a specific order of the response messages.

[0034] In the description herein, it should be understood that the orientations or positional relationships indicated by the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "circumferential" and the like are based on the orientations or positional relationships shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the devices or elements referred to must have a particular orientation, be constructed and operated in a particular orientation.

[0035] In the embodiments of the present application, the words such as "exemplary" or "for example" are used to mean serving as an example, instance, or illustration. Any embodiment or design presented as "exemplary" or "for example" in the embodiments of the present application should not be construed as being preferred or superior over other embodiments or design solutions. Rather, the use of the words such as "exemplary" or "for example" is intended to present relevant concepts in a concrete manner.

[0036] First, some technical terms that may be involved in the embodiments of the present application are introduced.

[0037] Node: also known as service node, used to run container groups and mesh agents. Exemplarily, an application program can be regarded as a node, and a node can run multiple container groups and at least one mesh agent, and each container group runs a service instance.

[0038] ETCD: an open source distributed key-value storage system used to store data in a cluster of machines. It is commonly used as a configuration storage for distributed systems such as Kubernetes, helping to manage and coordinate key information such as configurations, feature flags, etc.

[0039] Kata runtime: a runtime environment designed to provide a lightweight virtual machine (VM) similar to containers, with the security advantages of VMs while maintaining the performance and lightweight characteristics of containers. It enables users to run containerized applications in a more isolated and secure manner.

[0040] xDS server: provides configuration updates such as routing definitions, endpoint information, and policies to enable network proxies to implement service discovery, load balancing, and other traffic management capabilities suitable for modern microservice architectures.

[0041] Honeypot container: a running instance of a server (or application) image containing or simulating various vulnerabilities and false information, used to lure attackers to attack them, so that attack behaviors can be captured and analyzed.

[0042] Prometheus: in containerization and microservice architecture, Prometheus is widely used to monitor containers, service meshes, Kubernetes clusters, and other environments. It can efficiently handle large-scale data and work with other cloud-native tools such as Grafana to achieve visual monitoring and data analysis.

[0043] A Docker container (hereinafter referred to as a container) is a running instance of an image, which has the characteristics of fast deployment, portability and environment isolation. When a developer has an image file of a server (or an application), the developer can create a container generated according to the image file on a machine or a server by using container virtualization technology, so that the server (or the application) corresponding to the image file runs on the machine or the server. Since the container can run on almost any platform, such as a physical machine, a virtual machine, a public cloud, a private cloud, a personal computer, a server, etc., the containers running on the same platform are isolated from each other, a container is a complete execution environment, does not need to depend on the system environment of a carrier, and the overhead of a container runtime system is small. Therefore, a user can efficiently and conveniently migrate an application from one platform to another platform through the container.

[0044] A service mesh is a new service form including multiple nodes, which accesses an existing service to a service governance system through a network proxy to enjoy service registration, service discovery and service governance capabilities of the service.

[0045] Kubernetes is an open source container orchestration engine for managing containerized applications (APPs) on multiple hosts in a cloud platform. When deploying an application, multiple application instances of the application usually need to be deployed. In Kubernetes, multiple containers can be created for an application, and each container runs a service instance of the application.

[0046] A service instance can also be referred to as an instance of an application, an instance, an application instance, etc. An application can include one or more service instances. A service instance can be understood as a process of an application in a running environment.

[0047] A container is a way to implement operating system virtualization, which can allow a user to run an application and its dependencies in a process with isolated resources.

[0048] Embodiments of the present application provide an abnormal traffic management method, obtaining a path of traffic of a request in a service mesh; comparing the obtained path of traffic with an abnormal path in an attack source database; when the obtained path of traffic matches the abnormal path, marking the traffic as abnormal traffic; determining an abnormal service instance according to a matching result; creating a virtual service instance based on the abnormal service instance, and importing abnormal traffic of the abnormal service instance to the virtual service instance.

[0049] Figure 1 An architecture diagram of a service mesh is provided for embodiments of the present application. As shown in FIG. 1, the architecture of the service mesh includes a service mesh gateway, a service mesh controller, a service mesh proxy, a service mesh database, and a service mesh attack source database.Figure 1 As shown, the service mesh 100 includes a control plane and a data plane. The control plane serves as a central management unit, containing management components (e.g., xDS server), attack source database (e.g., etcd), and application interface components (e.g., API server). Within the control plane, traffic monitoring, anomaly detection, and defense policy generation are all accomplished by the components working together. The service mesh proxy monitors traffic and makes adjustments according to the policies issued by the control plane, ensuring that abnormal traffic is directed to the isolation environment while normal requests are safely processed. The components of the control plane can all be deployed on the same node, or they can be deployed on different nodes. The node can be a physical device or a virtual machine. The physical device can be a hardware server, a computer, etc.

[0050] The attack source database is used to store the paths of abnormal traffic generated by requests in the service mesh, as well as abnormal traffic data information. The application interface component provides an interface for communication within the service mesh and outside the service mesh. For example, an external user can use the Kubernetes API Server to create, update, and query service mesh resources.

[0051] The service mesh 100 also includes multiple nodes, each running one or more service instances that communicate through mesh proxies and handle requests from other nodes or the outside world while returning response results. Multiple mesh proxies work together to form the data plane of the service mesh 100. The node represents a physical or virtual machine that actually carries service instances and mesh proxy components.

[0052] A mesh proxy is deployed inside each node to manage all network traffic in and out of the node. For example, the mesh proxy is deployed in a containerized environment and manages communication between services. The service mesh proxy, such as Envoy, is deployed as a Sidecar container together with each service instance in the same node.

[0053] The data plane runs alongside each service instance, usually as a proxy (e.g., Envoy) deployed in a virtual machine or container on each node, responsible for traffic management, security policy enforcement, etc. between services. For example, an xDS server can be used to provide configuration and routing information for the data plane proxy (e.g., Envoy).

[0054] A service instance is a single running copy of a service in an application that can handle client requests and execute specific business logic. An application can be composed of multiple services, and each node can be considered as an application, with each service running in the service mesh as a service instance. For example, service instance A is a running instance of a service in application 1, while service instance B is a running instance of a service in application 2.

[0055] The mesh proxy is responsible for communication management between service instances, Figure 1 Service instance A communicates through mesh proxy A, and service instance B communicates through mesh proxy B. Each communication between service instances is intercepted and processed by the mesh proxy, which records the actual path information and traffic data information of each request, including request path, source IP address, request method, response status code, timestamp, and traffic size, etc. The mesh proxy can process different types of communication protocols (such as http, gRPC, etc.), and when a request passes through the mesh proxy, the mesh proxy will record and send the actual path information and traffic information (protocol type, traffic size, timestamp, etc.) to the control plane of the service mesh.

[0056] When a service (such as service instance A) communicates with another service (such as service instance B), the traffic first passes through the mesh proxy deployed next to the service instance. The mesh proxy intercepts the path of each traffic in and out of the service instance, which indicates the data transmission relationship of the request-generated traffic between service instances.

[0057] The control plane communicates with mesh proxy A and mesh proxy B, manages the traffic policy, configuration and control of the entire service mesh, and provides configuration data to mesh proxy A and mesh proxy B. The control plane includes management components (such as xds server), which, for example, issue policies to mesh proxies in the data plane through xds protocol, and collect the paths of the traffic of the requests uploaded by the proxies in the service mesh to ensure the communication path between service instances, traffic control and handling of abnormal requests. The control plane aggregates the paths of the traffic uploaded by the mesh proxies, and when the traffic passes through multiple service instances, the path recorded by each mesh proxy constitutes a local path. The control plane forms a complete traffic flow by sequentially combining multiple local paths. Each time the traffic passes through a new service instance, the path is dynamically extended. The control plane automatically integrates each new node (service instance) and edge (data transmission order of request-generated traffic between service instances) into the existing path to form the actual path of the traffic. Thus, a complete topology graph of communication between service instances is constructed, and the real flow of traffic is monitored.

[0058] The management component (such as xds server) can receive the path of the traffic from the service mesh proxy. When a new path of the traffic is received, first compare the path information of the traffic with the path information recorded in the attack source database to determine whether the traffic matches the path stored in the attack source database. If the path of the traffic matches the path information recorded in the database, the traffic is determined to be abnormal. If the path does not match the path in the database, the traffic is confirmed to be abnormal.

[0059] After determining the abnormal traffic, the path of the traffic is written into the database as an abnormal path to update the attack source database data and enhance the defense capability of the system. The abnormal injection point refers to the service instance that does not conform to the expectation in the path of the traffic, which is usually the starting point of the attack or abnormal behavior. The abnormal injection point can be determined by comparing the path with the path in the database.

[0060] Based on the determined abnormal injection point, the application interface component issues an instruction to create a virtual service instance through the control plane. It should be noted that the creation of the virtual service instance is created by multiple components in the control plane in cooperation, and other components are not shown in the Figure 1 The control plane deploys the virtual service instance to a suitable node according to the resource condition to simulate the environment of the attacked service instance. In a possible implementation, the management component in the control plane updates the traffic routing strategy of the service mesh according to the information of the abnormal service instance to guide the traffic into the newly created virtual service instance. All service instances on the path after the abnormal injection point will create corresponding virtual service instances by the application interface component, and the subsequent traffic will be guided into these newly created virtual service instances.

[0061] When the application interface component determines that a virtual service instance needs to be created, it instructs to start a virtual service instance (such as a honeypot Pod) on a node supporting a virtual isolation environment (such as kata-runtime) through a scheduling mechanism.

[0062] The control plane is responsible for the creation, start, scaling, scaling, and destruction of the virtual service instance. After the creation is completed, the connection to the virtual service instance is maintained to monitor its running state and perform necessary management operations.

[0063] Exemplarily, Kata-runtime is a lightweight virtual machine (VM) runtime that runs each virtual service instance in an independent virtual machine. Using Kata-runtime to run the virtual service instance provides higher isolation and security, prevents attackers from breaking through the honeypot environment, and ensures that abnormal traffic is isolated and induced to a safe environment for monitoring and analysis. Even if the attacker breaks through the virtual service instance, it is difficult to affect other service instances.

[0064] Figure 2 The schematic diagram of the path of the traffic generated in the service mesh is provided for the embodiments of the present application. As Figure 2 shown, in order to better understand the functions and actual operations of the modules in Figure 1 , the path of the traffic generated in the service mesh is provided for the embodiments of the present application. As Figure 2A specific implementation of a service mesh 100 is provided, exemplarily, the service mesh is a Kubernetes cluster, the control plane is divided into a service mesh control plane and a cluster control plane, Figure 1 The application program interface component in Figure 2 Corresponds to the API Server in Figure 1 The management component in Figure 2 Corresponds to the xds server in The attack source database corresponds to the etcd database of the cluster control plane. Figure 1 The service instance in Figure 2 Corresponds to the Pod in In a Kubernetes cluster deployed with a service mesh, the Envoy mesh proxy is responsible for collecting the paths between each service instance and uploading these paths to the Xds server of the service mesh control plane. After the Xds server receives the path, it compares the path with the paths stored in the etcd database. If the current path matches the path in the database, the xds server will determine that the traffic is abnormal traffic. After the xds server confirms that the traffic is abnormal, the xds server will write the path of the abnormal traffic to the etcd database. The etcd database can serve as an attack source database to record and store path and traffic data information.

[0065] In an implementation, the control plane can generate the configuration of the honeypot Pod based on the information of the path of the abnormal traffic, and deploy it to the appropriate node to simulate the target service instance under attack. For example: if the attack path points to / api / v1 / payment / trans, the newly created honeypot Pod can simulate the payment interface and be isolated from the normal payment processing service to induce the attacker to further expose the attack behavior. When deploying the honeypot Pod, the honeypot Pod can be placed in a specific namespace to isolate it from normal business services and avoid interfering with normal business.

[0066] Then, according to the path information of the identified abnormal traffic, the xds Server creates a new traffic forwarding policy to ensure that the abnormal traffic is redirected to the newly created honeypot Pod. The xds Server generates the traffic routing policy and issues it to the Envoy proxy rules of each node in the data plane update cluster to ensure that the abnormal traffic can be correctly directed to the honeypot Pod.

[0067] Please continue to refer to Figure 2 And Figure 1 A request is generated in the service mesh, the path of the normal traffic is: API Server→service instance A→service instance B, the path includes API Server, service instance A, service instance B, and other path nodes.

[0068] It can be understood that when the API Server communicates with the service instance A, the API Server is forwarded through the mesh proxy A, the API Server first communicates with the mesh proxy A, and then the mesh proxy A communicates with the service instance A, and the path of the traffic can include the API Server or the service instance A.

[0069] When the service instance A runs on the container A and the service instance B runs on the container B, the path of the traffic is: API Server→Pod A→Pod B. The path of the normal traffic can include the API Server, Pod A, Pod B.

[0070] If the traffic of the path: API Server→service instance A→service instance B is determined as abnormal traffic, the service instance A is determined as an abnormal injection point, the abnormal injection point indicates a path node that occurs abnormally on the path, and a virtual service instance corresponding to the path node after the abnormal injection point is created, then the part after the abnormal injection point of the traffic is introduced into the virtual service instance, and the new path of the abnormal traffic is: API Server→service instance A→virtual service instance. In the new path, the mesh proxy introduces the traffic into the virtual service instance according to the routing strategy issued, so as to realize isolation and induction of the abnormal traffic and prevent the influence on the real service instance B.

[0071] When the service instance A runs on the container A and the service instance B runs on the container B, a virtual container B can be created to run a virtual service instance, that is, if the traffic of the path: API Server→Pod A→Pod B is determined as abnormal traffic, the Pod A is determined as an abnormal injection point, and the new path of the abnormal traffic is: request→API Server→Pod A→virtual Pod B.

[0072] It can be understood that in a possible implementation, when the actual path part of the request is executed, if it is found that the path part is completely matched with the path part recorded in the attack source database, the request can be determined as abnormal traffic in advance, without waiting for the request to be executed in the service mesh.

[0073] For example, when the traffic of the request starts to pass through the service mesh, the Envoy mesh proxy continuously uploads the path segment of the request to the service mesh control plane, and compares the path segment with the abnormal path recorded in the database. If the path of the traffic of the request is executed to Pod A→Pod B, the path is completely consistent with the path recorded in the database (even if the subsequent path has not been executed), and the traffic is determined as abnormal traffic, and the Pod A is determined as an abnormal injection point.

[0074] After matching the abnormal path in the etcd database, the abnormal injection point is found, and the xds server notifies the API server to create a virtual service instance of the service instance on the path after the abnormal injection point.

[0075] The API Server module cooperates with other components in the cluster control plane to receive the request and perform the operation of creating a new Pod. Specifically, adjust ReplicaSet+1, which means adding a new Pod replica to the existing ReplicaSet. ReplicaSet is a resource object in Kubernetes used to manage a group of Pod replicas. Assuming that a ReplicaSet currently manages 3 Pods, adjusting ReplicaSet+1 requires Kubernetes to add 1 new Pod, making the number of Pod replicas 4.

[0076] kata-runtime is a container runtime used to run virtualization isolation environments, such as running virtual machines in containers. kata-runtime is used to provide stronger isolation. Kubernetes uses kata-runtime to start a virtual machine as a container when deploying a virtual service instance or honeypot Pod, providing higher security isolation than ordinary containers. Avoid kernel hijacking vulnerabilities and malicious information injection affecting other business environments.

[0077] For example, use containerization technology (such as Docker) to redeploy service instance B, ensure that its environment is reinitialized, and eliminate potential threats or malicious code that has been injected. According to the cluster resources, select the appropriate node and restart the service instance B container.

[0078] The Xds server updates the routing policy of the mesh proxy. The routing policy includes the destination of the traffic, the routing condition, the traffic processing method (such as retry, timeout, etc.), and whether it needs to be redirected to a new service instance. The service mesh proxy (such as Envoy) will receive these updates and change the way traffic is handled according to the new routing policy. For example, redirect traffic from the original target service instance (such as service instance A) to the new service instance. The Xds server will issue the new routing policy to the relevant service mesh proxy. Assuming that the request path is service instance A→service instance B, then proxy A and proxy B will receive this new routing policy. Mesh proxy A will redirect traffic from service instance A to virtual service instance B according to the new policy, achieving isolation of malicious traffic.

[0079] Based on the above description, a method for managing abnormal traffic according to an embodiment of the present application is described in detail.

[0080] Figure 3 is a flowchart of an abnormal traffic management method provided by an embodiment of the present application. The following describes the method provided by an embodiment of the present application in combination with Figure 1 and Figure 3 The method provided by an embodiment of the present application includes at least the following steps:

[0081] S301, acquiring a path of traffic generated by a request in a service mesh; the service mesh includes a plurality of service instances, and the path indicates a data transmission order of the traffic generated by the request between the service instances.

[0082] For example, after the request enters the service mesh, the mesh agent records the path of the traffic of the request in the service mesh. If the traffic is from service instance A to service instance B to service instance C, the mesh agent continuously uploads the path of the traffic to the management component. For example, service instance A is a user service, which is responsible for processing user login, registration, information query and other requests. Service instance B is an order service, which is used to process user order requests and perform operations such as creating, updating and querying orders. Service instance C is a payment service, which is responsible for processing payment requests of user orders, including payment verification and payment state updating.

[0083] For example, the path of the traffic of the request is from the user service (service A) to the order service (service B) and finally to the payment service (service C), and the corresponding path is generated in the service mesh. The mesh agent records and uploads the calling path between the service instances.

[0084] The request is forwarded from service instance A to service instance B, and the mesh agent records the actual path from service instance A to service instance B. The request is transmitted from service instance B to service instance C, and the mesh agent also records the actual path from service instance B to service instance C. That is, when the traffic of the request passes through the mesh agent, the mesh agent records each service instance and its order through which the traffic of the request passes, and constructs an actual path. These paths are continuously uploaded to the management component to construct the actual path of the traffic of the request.

[0085] In one possible implementation, the mesh agent constructs a directed graph of the path of the request by taking each node (N) as a service instance through which the request passes and taking the calling relationship (E) between the nodes as a directed edge each time the service instances communicate. The path is represented as Path=(N1,E1,N2,E2,...,En-1,En-1,Nn), where N1 is a starting node, Nn is a target node, and Ei is an edge from Ni to Ni+1. The mesh agent continuously collects the path information of the traffic of the request in the service mesh to form the path of the traffic of the request. The path of the traffic is uploaded to the management component.

[0086] For example, a request is initiated from service A, recorded as service A (N1) by the mesh proxy, targets service B (N2), and the communication edge is E1 (representing a call from service A to service B).

[0087] Next, service B calls service C, recorded as N2 = service B, target N3 = service C, and the edge is E2 (representing a call from service B to service C).

[0088] The path is represented as Path = (service A, E1, service B, E2, service C), and this path is uploaded to the management component.

[0089] S302, compare the path of the obtained traffic with the paths in the attack source database.

[0090] In one possible implementation, the attack source database generally stores abnormal path information in the form of multiple records, for example: service instance A→service instance B→service instance C.

[0091] It can be understood that when service instance A runs on container A and service instance B runs on container B, the path recorded in the attack source database can be service instance A→service instance B, or Pod A→Pod B. The management component can convert service instance A→service instance B to Pod A→Pod B for comparison, or convert Pod A→Pod B to service instance A→service instance B for comparison.

[0092] S303, when the path of the obtained traffic matches the path, mark the traffic as abnormal traffic.

[0093] The path recorded in the attack source database refers to a path in the service mesh that has been identified as abnormal. The path recorded in the attack source database can represent a common attack path or an abnormal access mode between certain service instances.

[0094] For example, the following service instances: service instance A: user authentication service, service instance B: order service, service instance C: payment service, service instance D: recommendation service, service instance E: log service

[0095] The path recorded in the attack source database records the following information:

[0096] Path 1: service instance A→service instance B→service instance D

[0097] This path usually appears in the payment process, and the normal path should be from service instance A to service instance B, and then to service instance C, but here, service instance B directly jumps to service D (recommended service). This may indicate that the request flow of a certain service instance is modified or bypassed, forming an unexpected path. For example, a user's request jumps directly to the recommendation service (service instance D) after order processing (service instance B), without going through the payment service (service instance C). This may indicate that a malicious user is trying to exploit system vulnerabilities for illegal operations, or that the system configuration is incorrect, causing traffic to bypass the normal business process.

[0098] In one possible implementation, if the path of the request is completely consistent with the path in the attack source database (for example, the path of the request is “service instance A→service instance B→service instance D”, that is, the attack source database records an abnormal path that is completely the same), it is considered that the traffic of the request is abnormal traffic.

[0099] In another possible implementation, if the path of the request contains the path in the attack source database, for example, the path of the request is “service instance C→service instance A→service instance B→service instance D”, it is considered that the request is abnormal traffic.

[0100] S304, according to the matching result, the management component determines the abnormal injection point.

[0101] In one possible implementation, the management component can determine the abnormal injection point according to the matching result, and then create a virtual service instance according to the abnormal injection point, and guide the traffic flowing out of the abnormal injection point into the virtual service instance.

[0102] The path matched by the attack source database can be an abnormal path, and the abnormal injection point can be the first path node on the abnormal path matched by the attack source database, for example, the abnormal path matched by the attack source database is: service instance A→service instance B→service instance D, and service instance A is the abnormal injection point.

[0103] S305, based on the abnormal injection point, the application program interface component creates a virtual service instance.

[0104] Suppose the path matched by the attack source database is: service instance A→service instance B→service instance D.

[0105] In a possible implementation, a virtual service instance can be created for each path node after the abnormal injection point, for isolating or processing abnormal traffic. For example, if service instance A is the abnormal injection point, a virtual service instance can be created for service instance B and service instance D, or a virtual container can be created for service instance B and service instance D, respectively, to run virtual service instance B and virtual service instance D. Then the abnormal traffic can be introduced to virtual service instance B after flowing out of service instance A. Alternatively, the traffic flowing from service instance A to service instance B can also be introduced to virtual service B, or the traffic flowing from service instance A to service instance D can also be introduced to virtual service D.

[0106] In a possible implementation, a virtual service instance can be created for the service instance corresponding to the first path node after the abnormal injection point, for isolating or processing abnormal traffic. For example, if service instance A is the abnormal injection point, a virtual service instance can be created for service instance B, or a virtual container can be created for service instance B, to run virtual service instance B. Then the abnormal traffic can be introduced to virtual service instance B after flowing out of service instance A. Alternatively, the traffic flowing from service instance A to service instance B can also be introduced to virtual service instance B, or the traffic flowing out of service instance A can also be introduced to virtual service instance B.

[0107] For example, after adding the virtual service instance, the number of ReplicaSet replicas in the service mesh increases by 1. Assuming that the original number of replicas is 3, it becomes 4 after increasing by 1, and Kubernetes will create new Pod instances for the virtual service instance. These newly created Pod instances will serve as honeypot Pods, for guiding and isolating malicious traffic. These Pod instances will be started by kata-runtime on specified nodes, and kata-runtime provides stronger isolation. By running these Pods in lightweight virtual machines, they can achieve more stringent isolation from other normal Pods, thereby preventing malicious attackers from further invading the real business environment.

[0108] S306, the management component introduces the abnormal traffic to the virtual service instance.

[0109] The method provided by the embodiments of the present application can actively monitor and identify the traffic path of the traffic generated by a request in a service mesh, analyze the path of the traffic, detect abnormal traffic, introduce a virtual service instance (honeypot Pod) in the service mesh once attack behavior (abnormal traffic) is found, introduce abnormal traffic, strongly isolate abnormal traffic and service instances, and monitor and identify abnormal traffic in the virtual service instance, so as to reduce the impact on the service mesh.

[0110] Figure 3 The method shown is only a basic embodiment of the method of the embodiments of the present application, and based on the basic embodiment, certain optimization and expansion can also obtain other preferred embodiments of the method.

[0111] In one embodiment, the embodiments of the present application make more comprehensive judgments and prevention on the abnormal traffic governance method based on the foregoing embodiments. After obtaining the actual path of the request traffic in the service mesh, if there is no path in the attack source database that matches the actual path, the path of the traffic generated by the request can be further compared with the initial path of the request. If the actual path of the request traffic and the initial path do not match, it indicates that the actual path of the request traffic in the service mesh deviates from the expected path, and therefore, the request traffic is determined to be abnormal traffic. Figure 4 is a flow diagram of an abnormal traffic governance method provided by the embodiments of the present application. As shown in Figure 4 The abnormal traffic governance method provided by the embodiments of the present application at least includes the following steps:

[0112] Step 401, the management component obtains the path of the traffic of the request in the service mesh; the path indicates the data transmission order of the traffic generated by the request between service instances.

[0113] For details, refer to the description of step 301, which will not be repeated.

[0114] Step 402, in the case that the obtained path of the traffic and the path in the attack source database cannot match, the management component compares the obtained path of the traffic with the initial path of the request.

[0115] In one possible implementation, when a request accesses a service in the service mesh, it first passes through an application program interface component to complete identity verification and access control, to ensure that the request has the permission to access the cluster. The application program interface component collects traffic data information of the request, including the initial path of the request. The initial path refers to the order of service instances through which the request flows, which is inferred based on the configured service link rules after the request is received by the application program interface component. By comparing with the initial path, it can also effectively determine whether the traffic of the request is abnormal.

[0116] For example, after the application interface component parses the request, the request triggers the sequential processing of multiple service instances in the cluster: service instance A: receives the order creation request. Service instance B: processes business logic, such as calculating the total price of the order. Service instance C: generates an order record. Service instance D: performs a payment operation, calls a payment gateway, and processes a payment request. Each service instance in the service mesh is pre-configured and defined in advance. The application interface component knows the functional implementation link of the request in advance, so when the request is parsed to obtain, for example, / api / v1 / order / create, the execution order of the corresponding service instance (for example, service instance A→service instance B→service instance C→service instance D) can be found. This is the expected path of the request in the service mesh and can be regarded as the initial path of the request.

[0117] In the case where the path of the request and the path in the database do not match, the path of the request and the initial path are compared to further determine whether the traffic of the request is abnormal traffic, and the path corresponding to the abnormal traffic is added to the attack source database, thereby facilitating subsequent comparison.

[0118] In step 403, in the case where the path of the traffic obtained and the initial path do not match, the management component marks the traffic as abnormal traffic and adds the path of the traffic obtained to the attack source database.

[0119] In a possible implementation, when the path of the traffic obtained is different from the initial path at any one path node, the traffic obtained can be marked as abnormal traffic, and the path of the traffic obtained is added to the attack source database in its entirety. For example, the initial path is: service instance A→service instance B→service instance C→service instance D→service instance E; the actual path is: service instance A→service instance B→service instance C→service instance F. The actual path (service instance A→service instance B→service instance C→service instance F) of the traffic obtained is compared with the initial path (service instance A→service instance B→service instance C→service instance D→service instance E). Since the actual path does not continue to proceed according to the initial path after service instance C, but jumps to service instance F, it can be determined that the traffic obtained is abnormal traffic, and therefore the path: service instance A→service instance B→service instance C→service instance F is added to the attack source database.

[0120] In a possible implementation, the path node of the acquired path different from the initial path, the path node before the path node, and all path nodes after the path node, and the connection relationship between the path nodes can also be added to the attack source database. For example, the path node of the service instance F is the path node of the path different from the initial path, and the path node (service instance F), the previous path node (service instance C), and all path nodes after the path node (none), and the connection relationship between the path nodes are added to the attack source database, that is, the path: service instance C→service instance F is added to the attack source database.

[0121] It can be understood that the path added to the attack source database is an abnormal path.

[0122] The initial path of the request is based on the predefined data transmission order between service instances, and the path is configured and verified in the service mesh in advance, indicating a normal traffic transmission process, and thus serving as a benchmark path for comparison with abnormal traffic. When the acquired traffic path cannot match the path in the attack source database, the actual traffic path is further compared with the initial path of the request. The comparison process can help to determine whether the traffic is abnormal.

[0123] Figure 5 FIG. 7 is a flow diagram of another abnormal traffic management method provided by an embodiment of the present application. The embodiment can be applied to the control plane of the service mesh. As shown in FIG. 7, the abnormal traffic management method provided by the embodiment of the present application at least includes the following steps. Figure 5

[0124] In step 501, the management component acquires traffic data information of path nodes of a path of traffic generated in the service mesh by a request.

[0125] In a possible implementation, when a request accesses a service in the service mesh, the application program interface component is first passed through to complete identity verification and access control, to ensure that the request has the permission to access the service mesh.

[0126] The management component can acquire traffic data information of path nodes (including the application program interface component) of a path of traffic generated in the service mesh by a request, and the traffic data information includes any one of an initial path of the request, and traffic source, port information, protocol type of the request, traffic size, and traffic timestamp. The traffic data information of the path node can be traffic data flowing out of the path node.

[0127] The initial path refers to an access path originally specified when the request is initiated.

[0128] ​Traffic source refers to the IP address of the client that initiates the request or the information of the source host, which can identify whether there is suspicious traffic from a specific IP or domain name, and is used to detect whether abnormal requests frequently come from a specific source.

[0129] Port information refers to the source port and target port used by the request, including client port and service instance port information. Monitoring port information can identify abnormal access behavior, such as frequent access to uncommon ports, which may indicate potential attacks.

[0130] Protocol type of request refers to the network protocol used by the request, such as HTTP / 1.1, HTTP / 2, gRPC, TCP, etc., which is used to identify abnormal protocols that do not conform to normal business processes.

[0131] Traffic size refers to the data size of the request, expressed in bytes, and monitoring traffic size can detect abnormal large data transmission to determine whether there is data leakage, DDoS attack, etc.

[0132] Traffic timestamp refers to the specific time point when the request occurs, usually recorded as a timestamp accurate to milliseconds. Through timestamp information, the access frequency and time interval of the request can be analyzed to determine whether there are frequent malicious requests or abnormally high request frequency.

[0133] The application program interface component collects traffic data information of the request,

[0134] For example, the request traffic data information can be specifically:

[0135] Source IP address: 192.168.1.100

[0136] Target IP address: 10.0.0.10

[0137] Target port: 8080

[0138] Request URI: / api / v1 / create

[0139] Protocol type: HTTP / 1.1

[0140] Request method: POST

[0141] Packet size: 500 bytes

[0142] Timestamp: 2024-11-20 10:05:00

[0143] For example, if the path of the traffic generated by the request is: application program interface component → service instance A → service instance B → service instance D, the management component can obtain the traffic data information of the request in each path node in the path.

[0144] Step 502, the management component matches the traffic data information with the traffic data information in the attack source database.

[0145] Multiple sets of traffic data information can be stored in the attack source database.

[0146] Step 503, in the case that the traffic data information matches the traffic data information in the attack source database, the management component determines that the traffic generated by the request is abnormal traffic.

[0147] If the traffic data information of a certain path node on the path of the traffic generated by the request is the same as each data in a set of traffic data information in the attack source database, it is determined that the traffic generated by the request is abnormal traffic.

[0148] S504, according to the matching result, the management component determines the abnormal injection point;

[0149] In a possible implementation, the abnormal injection point can be determined according to the matching result, and finally a virtual service instance is created according to the abnormal injection point, and the traffic flowing out of the abnormal injection point is introduced into the virtual service instance.

[0150] When the traffic data information of only one path node on the path of the traffic generated by the request matches the traffic data information in the attack source database, the path node is determined as the abnormal injection point.

[0151] When the traffic data information of multiple path nodes on the path of the traffic generated by the request matches the traffic data information in the attack source database, the abnormal path in the path of the traffic can be determined according to the multiple path nodes, and then the first path node in the abnormal path is taken as the abnormal injection point.

[0152] S505, the application program interface component creates a virtual service instance based on the abnormal injection point. This step is similar to S305 and will not be repeated here.

[0153] S506, the management component introduces the abnormal traffic into the virtual service instance.

[0154] This step is similar to S306 and will not be repeated here.

[0155] The method provided by the embodiments of the present application can further determine abnormal traffic by comparing traffic data information in addition to path comparison. The dual verification of path comparison and traffic data information can more efficiently and comprehensively identify and isolate abnormal traffic, and further improve the security defense capability of the service mesh.

[0156] Figure 6 Another flowchart of an abnormal traffic management method provided by the embodiments of the present application is shown in FIG. 6. As shown in FIG. 6, the method comprises the following steps.Figure 6 As shown, the abnormal flow management method provided by the embodiments of the present application at least includes the following steps:

[0157] Step 601, the management component acquires the traffic data information of the path node of the path of the traffic generated in the service mesh.

[0158] This step is similar to S501, and will not be repeated here.

[0159] Step 602, in the case that the traffic data information of the request and the traffic data information in the attack source database do not match, the traffic data information of the request is matched with the alarm rule, and the alarm rule is used to indicate abnormal traffic data information.

[0160] Step S603, in the case that the traffic data information of the request matches at least one of the alarm rules, the traffic data information of the request is added to the attack source database.

[0161] In the case that the traffic data information of the request matches at least one of the alarm rules, the traffic data information of this request is added to the attack source database as a group of traffic data information.

[0162] For example, the alarm statistical rule of abnormal flow is as follows:

[0163] Example 1: expr:sum(rate(kube_proxy_tcp_sessions_total{direction="inbound",pod=~".*"}[1m]))by(source_ip)>100

[0164] kube_proxy_tcp_sessions_total: This is a metric in Prometheus that tracks the total number of TCP sessions handled by the Kubernetes proxy.

[0165] {direction="inbound"}: Filter the metrics of inbound traffic.

[0166] pod=~".*": Match all Pods.

[0167] [1m]: Calculate the rate of change in the past 1 minute.

[0168] by(source_ip): Group the results by source IP address.

[0169] 100: Set the threshold to trigger the alarm, if the rate sum exceeds 100 sessions per second.

[0170] Example 1 sets an alert rule in a Kubernetes cluster to monitor the rate of incoming TCP sessions to Kubernetes Pods. When the rate of incoming TCP sessions from a certain source IP exceeds 100 sessions per second in the past 1 minute, an alert is triggered and the IP is recorded as a potential malicious traffic source.

[0171] Example 2: sum(rate(container_network_transmit_bytes_total{namespace="default",pod=~".*"}[5m])) by(pod) > 1e9

[0172] container_network_transmit_bytes_total: This is a metric in Prometheus that tracks the total number of bytes transmitted by a container.

[0173] {namespace="default"}: Limits the metric to the default namespace;

[0174] pod=~".*": Matches all Pods (can specify specific business corresponding to the pod);

[0175] [5m]: Calculate the rate of change in the past 5 minutes;

[0176] by(pod / Service): Group the results by Pod / Service;

[0177] 1e9: Set the threshold for triggering an alert if the total number of transmitted bytes exceeds 1 billion bytes per second.

[0178] Example 2 is used to monitor the network traffic transmitted by each Pod in the default namespace. Prometheus continuously monitors the container_network_transmit_bytes_total metric, recording the network traffic rate transmitted by each Pod in the past 5 minutes. When the outbound traffic rate of a certain Pod exceeds 1 billion bytes per second (1 GB / s) in 5 minutes, the monitoring tool Prometheus will trigger an alert according to the configured alert rule.

[0179] The above is only a schematic of the two alert rules given, other alert rules can be configured, for example: high-frequency request rule: if a certain IP sends more than a preset number of requests to a certain service in a short period of time, an alert is triggered. Abnormal status code monitoring: detect the frequency of requests returning abnormal status codes (such as 404, 500), if it exceeds the threshold, trigger an alert. Alert rules can be flexibly configured to deal with different abnormal traffic situations, ensuring timely identification and taking defensive measures.

[0180] In a possible implementation, the alert rule is set in a monitoring tool, for example, Prometheus, which can be deployed outside the control plane, for example, on a dedicated hardware node or virtual machine.

[0181] In another possible implementation, the anomaly detection on the traffic data information of the request can be implemented through a custom script, which is not limited in the present application.

[0182] Figure 7 A flowchart of another anomaly traffic management method provided by an embodiment of the present application is shown in FIG. 7. Figure 7 As shown in FIG. 7,

[0183] In step S701, the application service interface component verifies the request.

[0184] When the request arrives at the cluster, for example, a Kubernetes cluster, the APIServer first performs client authentication to verify whether the identity information (such as a certificate, a token) of the request meets the preset access permission. Then, the APIServer performs resource legality verification to check whether the request meets the resource quota, policy and access control rule of the cluster, so as to ensure that the request has sufficient permission and meets the security and resource configuration requirements of the cluster.

[0185] In step S702, the management component obtains the traffic data information of the request.

[0186] In step S703, the management component determines whether the traffic data information of the request matches the traffic data information recorded in the attack source database. If yes, go to step S710. If no, go to step S704.

[0187] In step S704, based on the preset alert rule, if the traffic data information of the request matches at least one alert rule, go to step S705. If the traffic data information of the request does not match the alert rule, go to step S706.

[0188] In step S705, the traffic is marked as abnormal traffic, and the traffic data information of the request is written into the attack source database.

[0189] In step S706, the management component collects the path of the traffic of the service mesh.

[0190] In step S707, the obtained path of the traffic is compared with the path in the attack source database. If the obtained path of the traffic matches the path in the attack source database, go to step S710. Otherwise, go to step S708.

[0191] Step S708, the path of the acquired traffic is compared with the initial path of the request, and in a case where the acquired traffic path and the initial path cannot be matched, step S709 is jumped to. Otherwise, step S713 is jumped to.

[0192] Step S709, the traffic is marked as abnormal traffic, and the acquired traffic path is added to the attack source database.

[0193] Step S710, after steps S705 and S709 are executed, step S710 is jumped to, and the abnormal injection point is determined.

[0194] Step S711, based on the abnormal injection point, a corresponding virtual service instance is newly created.

[0195] Step S712, the abnormal traffic is imported into the virtual service instance.

[0196] Step S713, no abnormal traffic is found, the request continues to be executed according to a predetermined normal path, and finally reaches the target service instance.

[0197] The application also provides an abnormal traffic management device 800, comprising a management component 810, configured to acquire a path of traffic of a request in a service mesh; the service mesh comprises a plurality of service instances, and the path indicates a data transmission order of traffic generated by the request between the service instances; the acquired traffic path is compared with a path in an attack source database; in a case where the acquired traffic path and the path in the attack source database are matched, the acquired traffic is marked as abnormal traffic; according to a matching result, an abnormal injection point is determined, and the abnormal traffic is imported into a virtual service instance. An application program interface component 820 is configured to create a virtual service instance based on the abnormal injection point; and an attack source database 830 is configured to store the path of the abnormal traffic.

[0198] The application also provides a service mesh 900, comprising: a management component 910, configured to acquire a path of traffic generated by a request in a service mesh; the service mesh comprises a plurality of service instances, and the path indicates a data transmission order of traffic generated by the request between the service instances; the acquired traffic path is compared with a path in an attack source database; in a case where the acquired traffic path and the path in the attack source database are matched, the acquired traffic is marked as abnormal traffic; according to a matching result, an abnormal injection point is determined, the abnormal injection point is used to indicate an abnormal path node in the path of the traffic generated by the request; and the abnormal traffic is imported into a virtual service instance; an application program interface component 920 is configured to create a virtual service instance based on the abnormal injection point; and an attack source database 930 is configured to store the path of the abnormal traffic; a plurality of nodes 940, each of which runs at least one service instance.

[0199] Based on the same concept as the method embodiments of the present application, the embodiments of the present application also provide a computing device 1000. The computing device runs computer program instructions to execute Figure 3 or Figure 4 or Figure 5 or Figure 6 The method provided in the foregoing embodiments. The computing device can include a processor, which can be coupled with a memory for storing a program, the memory storing executable program code, and the processor executing the executable program code to respectively implement the functions of the foregoing management component, application program interface component, attack source database, thereby implementing the abnormal traffic governance method. That is, the memory has instructions for executing the abnormal traffic governance method. When the program stored in the memory is executed, the computing device executes the method provided in Figure 3 or Figure 4 or Figure 5 or Figure 6 The foregoing embodiments. Among them, the memory can be integrated in a chip or a processor, or independent of the chip or the processor. The computing device can be a server.

[0200] Based on the method in the above embodiments, the embodiments of the present application provide a computer readable storage medium, which stores a computer program, and when the computer program is run on a processor, the processor executes the method in the above embodiments.

[0201] Based on the method in the above embodiments, the embodiments of the present application provide a computer program product, characterized in that when the computer program product is run on a processor, the processor executes the method in the above embodiments.

[0202] It should be understood that each step of the above method embodiments can be completed by a logic circuit in the form of hardware in the processor or instructions in the form of software.

[0203] It can be understood that the size of the serial number of each step in the above embodiments does not mean the order of execution, and the execution order of each process should be determined according to its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. In addition, in some possible implementations, each step in the above embodiments can be selectively executed, partially executed, or fully executed according to the actual situation, which is not limited here.

[0204] It can be understood that the processor in the embodiments of the present application can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. The general-purpose processor can be a microprocessor or any conventional processor.

[0205] The method steps in the embodiments of the present application can be implemented in the form of hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, and the software modules can be stored in a random access memory (RAM), a flash memory, a read-only memory (ROM), a programmable read-only memory (PROM), an erasable PROM (EPROM), an electrically EPROM (EEPROM), a register, a hard disk, a mobile hard disk, a CD-ROM or any other form of storage medium well known in the art. An exemplary storage medium is coupled to the processor, so that the processor can read information from and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and the storage medium can be located in an ASIC.

[0206] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated. The computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions can be stored in or transmitted by a computer readable storage medium. The computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center through a wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) manner. The computer readable storage medium can be any available medium accessible by a computer or a data storage device such as a server, data center, etc. integrated with one or more available media. The available media can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid state disk (SSD)) and the like.

[0207] It can be understood that various numerical numbers involved in the embodiments of the present application are only distinguished for convenience of description, and are not used to limit the scope of the embodiments of the present application.

Claims

1. An abnormal traffic governance method, characterized in that, The method comprises: acquiring a path of traffic generated by a request in a service mesh; the service mesh comprises a plurality of service instances, and the path indicates a data transmission sequence of the traffic generated by the request between the service instances; comparing the acquired path of the traffic with paths in an attack source database; in a case where the acquired path of the traffic matches a path in the attack source database, marking the acquired traffic as abnormal traffic; determining an abnormal injection point in the path of the traffic generated by the request according to a matching result, the abnormal injection point being used to indicate an abnormal path node in the path of the traffic generated by the request; creating a virtual service instance based on the abnormal injection point; and directing the abnormal traffic to the virtual service instance.

2. The method of claim 1, wherein, The comparison of the acquired path of the traffic with the paths in the attack source database comprises: in a case where the acquired path of the traffic cannot match the paths in the attack source database, comparing the acquired path of the traffic with an initial path of the request; in a case where the acquired path of the traffic cannot match the initial path, marking the traffic as abnormal traffic and adding the acquired path of the traffic to the attack source database.

3. The method according to any of claims 1-2, characterized in that, The determination of the abnormal injection point in the path of the traffic according to the matching result comprises: the abnormal injection point being a first path node on an abnormal path obtained by the matching result.

4. The method according to any one of claims 1-2, characterized in that, The method further comprises: acquiring traffic data information of a path node of the path of the traffic generated by the request in the service mesh, the traffic data information comprising any one of an initial path of the request, a traffic source, port information, a protocol type of the request, traffic size and a traffic timestamp; comparing the traffic data information of the request with traffic data information in the attack source database; in a case where the traffic data information of the request matches the traffic data information in the attack source database, determining that the traffic generated by the request is abnormal traffic.

5. The method of claim 4, wherein, The comparison of the traffic data information of the request with the traffic data information in the attack source database comprises: in a case where the traffic data information of the request does not match the traffic data information in the attack source database, matching the traffic data information of the request with an alarm rule, the alarm rule being used to indicate abnormal traffic data information; in a case where the traffic data information of the request matches at least one alarm rule, adding the traffic data information of the request to the attack source database.

6. The method of claim 5, wherein, The determination of the abnormal injection point in the path of the traffic according to the matching result comprises: when only traffic data information of one path node on the path of the traffic generated by the request matches traffic data information in the attack source database, determining the path node as the abnormal injection point; or when traffic data information of a plurality of path nodes on the path of the traffic generated by the request matches the traffic data information in the attack source database, determining an abnormal path in the path of this traffic according to the plurality of path nodes, and determining a first path node in the abnormal path as the abnormal injection point.

7. The method according to any one of claims 1-2, characterized in that, The creation of the virtual service instance based on the abnormal injection point comprises: create a virtual service instance using the image file of the service instance corresponding to the first path node after the abnormal injection point. create a virtual service instance using the image file of the service instance corresponding to the first path node after the abnormal injection point.

8. An abnormal traffic governance apparatus, characterized by, comprising a management component configured to obtain a path of traffic generated by a request in a service mesh; the service mesh comprises a plurality of service instances, and the path indicates a data transmission order of the traffic generated by the request between the service instances; compare the obtained path of the traffic with paths in an attack source database; and in a case where the obtained path of the traffic matches a path in the attack source database, mark the obtained traffic as abnormal traffic; determine an abnormal injection point according to a matching result; and direct the abnormal traffic to a virtual service instance; an application program interface component configured to create a virtual service instance based on the abnormal injection point; the attack source database is configured to store paths of abnormal traffic.

9. A service mesh system, comprising: comprising a management component configured to obtain a path of traffic generated by a request in a service mesh; the service mesh comprises a plurality of service instances, and the path indicates a data transmission order of the traffic generated by the request between the service instances; compare the obtained path of the traffic with paths in an attack source database; and in a case where the obtained path of the traffic matches a path in the attack source database, mark the obtained traffic as abnormal traffic; determine an abnormal injection point according to a matching result, the abnormal injection point being used to indicate an abnormal path node in the path of the traffic generated by the request; and direct the abnormal traffic to a virtual service instance; an application program interface component configured to create a virtual service instance based on the abnormal injection point; the attack source database is configured to store paths of abnormal traffic; a plurality of nodes, each node running at least one service instance.

10. A computing device, comprising: comprising a processor and a memory, the processor being configured to execute instructions stored in the memory to perform the method of any one of claims 1 to 7.

Images