CN115766525A

CN115766525A - Container flow collection method and device, storage medium and equipment

Info

Publication number: CN115766525A
Application number: CN202211434794.3A
Authority: CN
Inventors: 刘浩; 蒋凯; 冯顾; 陈晨; 毛龙松
Original assignee: Qax Technology Group Inc; Secworld Information Technology Beijing Co Ltd
Current assignee: Qax Technology Group Inc; Secworld Information Technology Beijing Co Ltd
Priority date: 2022-11-16
Filing date: 2022-11-16
Publication date: 2023-03-07

Abstract

In the method, a client deployed on a Linux host acquires an acquisition strategy issued by a server, performs container traffic acquisition on a veth-pair virtual network card of a container to be acquired on the Linux host according to the acquisition strategy, and reports the acquired container traffic to a detection system. Therefore, various container deployment modes are supported, and an independent flow acquisition rule is configured for each container to be acquired, so that the configuration is more flexible and richer, and the standardization and the commercialization are easy.

Description

Container flow collection method and device, storage medium and equipment

Technical Field

The application relates to the technical field of containers, in particular to a container flow acquisition method, a container flow acquisition device, a storage medium and electronic equipment.

Background

With the development of container technology, especially with large-scale container cluster management systems, such as kubernets (K8S for short), which are referred to as IT infrastructure, more and more business systems are deployed in containers. The traditional intrusion detection tool based on network flow cannot collect container flow, so that the container flow becomes a detection blind area and threatens the safety of a service system.

The manner of collecting container traffic in the related art is generally related to the deployment manner of the container, for example, when the container is deployed by a Docker, the container traffic is collected from a Docker0 virtual bridge; when deployed through K8S, a virtual bridge created using the K8S network module, such as Cni bridge, catches up packets. Such a method is not universal enough, and is difficult to make into a standardized product, and moreover, the collection rule cannot be configured for a single container, which is not beneficial to commercialization.

Disclosure of Invention

An embodiment of the application aims to provide a container flow acquisition method, a device, a storage medium and equipment, and aims to solve the problems that a scheme for acquiring container flow in the related art is not universal enough, cannot configure an independent acquisition rule for a single container, and is difficult to standardize and commercialize.

In a first aspect, a container traffic collection method provided in an embodiment of the present application is applied to a client deployed on a Linux host, where at least one container runs on the Linux host, and the method includes:

acquiring an acquisition strategy issued by a server, wherein the acquisition strategy comprises a container to be acquired and a corresponding flow acquisition rule;

according to the acquisition strategy, applying a corresponding flow acquisition rule to acquire the container flow of the veth-pair virtual network card of the container to be acquired;

and sending the collected container flow to a detection system.

In the implementation process, the client deployed on the Linux host acquires the acquisition strategy issued by the server, and according to the acquisition strategy, the veth-pair virtual network card of the container to be acquired is used for acquiring the container flow on the Linux host, and the acquired container flow is reported to the detection system. Therefore, various container deployment modes are supported, and independent flow acquisition rules are configured for each container to be acquired, so that the configuration is more flexible and richer, and the standardization and the productization are easy.

Further, in some embodiments, the collection policy carries container asset information of the container to be collected, where the container asset information includes at least one of:

container ID, container name, MAC address, IP address, veth-pair virtual network card name.

In the implementation process, the type of the container asset information is limited, and the client can conveniently determine the container to be collected.

Further, in some embodiments, the container asset information is obtained by the server through an API provided by a container deployment platform; and/or the container asset information is reported to the server by the client.

In the above implementation, a specific way of collecting container asset information is provided to improve the integrity of the collected container asset information.

Further, in some embodiments, the performing, according to the collection policy, container traffic collection on the veth-pair virtual network card of the container to be collected by applying a corresponding traffic collection rule includes:

determining a veth-pair virtual network card of the container to be collected according to the container asset information;

and acquiring the container flow of the veth-pair virtual network card by applying a corresponding flow acquisition rule.

In the implementation process, the path-pair virtual network card corresponding to the container to be acquired is determined according to the container asset information in the acquisition strategy, so that container flow acquisition is carried out, and accurate acquisition according to configuration is realized.

Further, in some embodiments, the traffic collection rules include at least one of:

BPF filtering rules and speed limit threshold values.

In the implementation process, the BPF filtering rules and/or the speed limit threshold value are configured, so that the productization of the acquisition technology is facilitated.

Further, in some embodiments, the method further comprises:

and counting the container flow of each container, and reporting the counting result to the server.

In the implementation process, a statistical function for the container flow of each container is provided, and after the client reports the statistical result to the server, the client can provide reference for configuring the acquisition strategy for the user, and provide data support for adjusting the acquisition strategy to be more reasonable.

Further, in some embodiments, the traffic collection rule is configured based on:

if the container flow of any container to be collected exceeds a first preset threshold value, the BPF filtering rule configured for the container to be collected comprises at least one of a designated IP address, a designated port and a designated protocol;

and if the counted container flow of any container to be collected does not exceed a second preset threshold, the BPF filtering rule configured for the container to be collected is empty.

In the implementation process, a specific mode of adjusting the flow acquisition rule according to the statistical result is provided, the balance of data acquisition requirements and bandwidth limitation during container flow detection is met, and the adjusted acquisition strategy is more reasonable.

Further, in some embodiments, the server provides a configuration interface, and the configuration interface is used for a user to configure the acquisition policy.

In the implementation process, the user can configure the acquisition strategy on the server side, so that the personalized configuration of the acquisition strategy is realized, and the customized requirements of the user are met.

Further, in some embodiments, the sending the collected container flow to a detection system includes:

and encapsulating the collected container flow into a VXLAN format or a GRE format, and then sending the encapsulated container flow to a detection system.

In the implementation process, the client performs VXLAN/GRE encapsulation on the collected container traffic, so that the encapsulated container traffic can be transmitted to the detection system.

Further, in some embodiments, the method further comprises:

when a new acquisition strategy issued by a server is acquired, applying a flow acquisition rule in the new acquisition strategy to acquire container flow of a veth-pair virtual network card of a container to be acquired in the new acquisition strategy.

In the implementation process, when a user configures a new acquisition strategy, the client acquires the container flow according to the new acquisition strategy, so that the user can conveniently adjust the acquisition strategy, and the use experience of the user is improved.

In a second aspect, an embodiment of the present application provides a container traffic collection apparatus, which is applied to a client deployed on a Linux host, where at least one container runs on the Linux host, and the apparatus includes:

the acquisition module is used for acquiring an acquisition strategy issued by a server, wherein the acquisition strategy comprises a container to be acquired and a corresponding flow acquisition rule;

the acquisition module is used for acquiring the container flow of the veth-pair virtual network card of the container to be acquired by applying a corresponding flow acquisition rule according to the acquisition strategy;

and the sending module is used for sending the acquired container flow to the detection system.

In a third aspect, an electronic device provided in an embodiment of the present application includes: memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the steps of the method according to any of the first aspect when executing the computer program.

In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having instructions stored thereon, which, when executed on a computer, cause the computer to perform the method according to any one of the first aspect.

In a fifth aspect, embodiments of the present application provide a computer program product, which when run on a computer, causes the computer to perform the method according to any one of the first aspect.

Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the above-described techniques.

In order to make the aforementioned objects, features and advantages of the present application more comprehensible, preferred embodiments accompanied with figures are described in detail below.

Drawings

To more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments of the present application will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and that those skilled in the art can also obtain other related drawings based on the drawings without inventive efforts.

Fig. 1 is a flowchart of a container flow rate collecting method provided in an embodiment of the present application;

fig. 2 is a schematic diagram of an overall architecture of a container flow collection system according to an embodiment of the present disclosure;

fig. 3 is a block diagram of a container flow rate collecting device according to an embodiment of the present disclosure;

fig. 4 is a block diagram of an electronic device according to an embodiment of the present disclosure.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application.

It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures. Meanwhile, in the description of the present application, the terms "first", "second", and the like are used only for distinguishing the description, and are not to be construed as indicating or implying relative importance.

As described in the background art, the related art scheme for collecting the flow rate of the container has the problem that standardization and commercialization are difficult. Based on this, the embodiment of the present application provides a container flow rate acquisition scheme to solve this problem.

Next, embodiments of the present application will be described:

as shown in fig. 1, fig. 1 is a flowchart of a container traffic collection method provided in an embodiment of the present application, where the method may be applied to a client deployed on a Linux host. The Linux host can be a host configured by an operating system based on a Linux kernel, and can be a physical machine or a virtual machine; the operating system based on the Linux kernel can be any one of CentOS, debian, ubuntu and the like. In this embodiment, at least one container runs on the Linux host, and one container contains a complete runtime environment, and in addition to the application program itself, dependencies, class libraries, other binary files, configuration files, and the like required by the application are uniformly driven into a package called a container image. By containerization, differences caused by operating system release versions and other underlying environments are abstracted away. When a plurality of containers are operated on the Linux host, processes in the containers are isolated from each other and cannot be sensed mutually, and the upgrading or the failure of one container cannot affect other containers. The client here is an application program that performs the method steps of the present embodiment for collecting container traffic.

The method comprises the following steps:

in step 101, acquiring an acquisition policy issued by a server, wherein the acquisition policy comprises a container to be acquired and a corresponding flow acquisition rule;

the server mentioned in this step may be a program corresponding to the client and providing a service to the client. The server can be deployed on the container deployment platform and used for issuing services corresponding to the acquisition strategies to the Linux hosts. The server and the client can communicate based on HTTP (Hyper Text Transfer Protocol) or other communication modes.

In this embodiment, the server issues an acquisition policy to the client, where the acquisition policy includes a container to be acquired and a corresponding traffic acquisition rule. That is, the collection policy here indicates the container to be collected and the specific rules when collecting the container traffic for that container. The container to be collected may be all or part of the container on the Linux host, for example, when two containers run on the Linux host, the container to be collected may be the two containers, or may be any one of the two containers.

To facilitate the client determining the container to be collected, in some embodiments, the collection policy may carry container asset information of the container to be collected, where the container asset information may include at least one of the following: container ID, container name, MAC address, IP address, veth-pair virtual network card name. Taking the example that the container deployment platform is a Docker, the Docker can automatically generate a random name for a container when the container is created, create a container ID for the container, and generate a MAC address by using an IP address assigned to the container to avoid ARP collision; the method comprises the steps that a path-pair is a pair of virtual device interfaces, in a Linux system, a container network card is created through a path-pair virtual network device, the container network card is one end of the path-pair, a Linux host is provided with the other end of the path-pair corresponding to the virtual network card, network flow sent and received when the container runs can pass through the path-pair virtual network card corresponding to the Linux host, and by utilizing the principle, the path-pair virtual network card name can be collected to serve as container asset information, so that the path-pair virtual network card corresponding to a container to be collected is determined, and container flow collection is further carried out. Of course, in other embodiments, the container asset information may also include other information, which is not limited in this application.

Further, in some embodiments, the container asset information may be obtained by the server through an API provided by the container deployment platform; and/or the container asset information is reported to the server side by the client side. Some related information of the containers running on the Linux hosts is recorded on the container deployment platform, so that the server side can query and collect the container asset information to a certain extent through an API (application programming interface) provided by the container deployment platform. The client is deployed on the Linux host and can acquire some related information of the container running on the Linux host, so that the server can acquire the container asset information to a certain extent by reporting the information by the client. Preferably, both collection modes may be performed simultaneously to improve the integrity of the collected container asset information. Of course, in other embodiments, other collection means may be employed.

The traffic collection rule mentioned in this step is a filtering rule and/or a restriction rule when the client collects container traffic. In some embodiments, the traffic collection rules may include at least one of: BPF filtering rules and speed limit thresholds. BPF (Berkeley Packet Filter) is a kind of original interface of data link layer on Unix-like system, provides transceiving of original link layer packets, and supports filtering of data packets. The setting of the BPF filtering rule is to make the network device only capture the network data packets which are interested by the user, such as the data packets which are transmitted and received through the appointed port, the data packets based on the appointed protocol, and the like; and if no BPF filtering rules are set, the network device will capture all types of packets. The speed limit threshold is a critical value of container flow normally collected by the client, and for a container with larger flow, the limitation of an external network bandwidth sent to the detection system needs to be considered in the actual collection process, so that the speed limit threshold is set, and when the container flow collected within a certain time period reaches the speed limit threshold, the client reduces the frequency of collecting the container flow and even temporarily stops collecting the container flow. The BPF filtering rules and/or the speed limit threshold value are configured, so that the productization of the acquisition technology is facilitated. Additionally, in other embodiments, the traffic collection rules may also include other content, such as collection interval time, etc.

Additionally, in some embodiments, the server may provide a configuration interface that may be used by a user to configure the acquisition policy. That is, after the server collects the container asset information, the user may configure a collection policy on the server, and specify the container to be collected and the corresponding traffic collection rule. For example, a Linux host runs three containers, namely container 1, container 2 and container 3, a user can configure only acquisition container 1 and container 3 on a server, and can configure only capturing data packets sent and received by a specified port as a traffic acquisition rule for container 1 and only capturing data packets based on a specified protocol as a traffic acquisition rule for container 3. Therefore, the personalized configuration of the acquisition strategy is realized, and the customized requirements of the user are met.

In step 102, according to the collection strategy, applying a corresponding flow collection rule to collect the container flow of the veth-pair virtual network card of the container to be collected;

the container traffic refers to network traffic transmitted and received during the operation of the container, and the container traffic collection is to collect data packets transmitted and received during the operation of the container. For the client, the network traffic received and sent by the network card in the container cannot be directly acquired, but in this embodiment, the container traffic acquisition is performed on the veth-pair virtual network card of the container to be acquired by applying the traffic acquisition rule in the acquisition policy by using the principle that the network traffic received and sent during the operation of the container passes through the corresponding veth-pair virtual network card, so that the universal container traffic acquisition is realized.

Specifically, in some embodiments, this step may include: determining a path-pair virtual network card of a container to be collected according to container asset information carried in a collection strategy; and acquiring the container flow of the path-pair virtual network card by applying a corresponding flow acquisition rule. That is to say, the client may determine a container to be collected according to the container asset information carried in the collection policy, determine a veth-pair virtual network card corresponding to the container, and then apply a corresponding traffic collection rule to capture a packet, thereby realizing collection of container traffic. It should be noted that, when the container asset information does not include the veth-pair virtual network card name, the client may query the corresponding veth-pair virtual network card name according to other container asset information, such as the IP address of the container to be acquired, and further determine the veth-pair virtual network card corresponding to the container to be acquired.

And the client acquires the path-pair virtual network cards of different containers according to an acquisition strategy, and applies different BPF filtering rules and/or speed limit thresholds. Continuing with the previous example, after receiving the collection strategy, the client collects the path-pair virtual network card of the container 1 and only captures the data packet received and sent by the designated port; the veth-pair virtual network card of the container 2 is not collected; the path-pair virtual network card of the container 3 is collected, and only the data packet based on the specified protocol is captured.

In this embodiment, a user configures an acquisition policy at a server, and a client performs container traffic acquisition according to the acquisition policy, without depending on a specific module of a container deployment platform, so that the method is a general container traffic acquisition method, and supports various container deployment modes including but not limited to Docker deployment and K8S deployment, thereby facilitating standardization and commercialization.

In step 103, the collected container flow is sent to a detection system.

The detection system mentioned in the step is a tool for performing statistical analysis on network traffic and detecting malicious or suspicious traffic, thereby ensuring the safety of a service system. Alternatively, the Detection System may be a NIDS (Network Intrusion Detection System). NIDS refers to a combination of software and hardware that detects behavior that compromises computer system security, such as collecting vulnerability information, causing denial of access, and obtaining system control rights that are outside of a legal range. After the client sends the collected container traffic to NIDS, the NIDS provides the container traffic as data to its IDS analysis engine component, which finds out possible intrusion behavior by means of statistics or rules and provides the event to its response component, which takes corresponding behavior, such as actively notifying system administrator, interrupting the connection of intruder and searching intrusion information. Of course, in other embodiments, the detection system may also be other types of network traffic detection tools, which is not limited in this application.

Specifically, in some embodiments, this step may include: and packaging the collected container flow into a VXLAN format or a GRE format, and then sending the obtained container flow to a detection system. The VXLAN (Virtual Extensible Local Area Network) format is a Network data packet encapsulation format, and the message encapsulation is to encapsulate a two-layer ethernet frame into a UDP packet, and to add a VXLAN header to identify a different two-layer Network. The GRE (Generic Routing Encapsulation) format is also a network data packet Encapsulation format, which provides a mechanism for encapsulating a message of one protocol into a message of another protocol, and is a three-layer tunnel Encapsulation technique. And when the client acquires one message, carrying out VXLAN/GRE encapsulation on the message, so that the encapsulated message can be transmitted to a detection system. Of course, in other embodiments, other packaging formats may be used, and the present application is not limited thereto.

Further, in some embodiments, the method may further include: and counting the container flow of each container, and reporting the counting result to the server. That is to say, the client may provide a statistical function for the container traffic of each container in addition to the function of collecting the container traffic, and after reporting the statistical result to the server, the client may provide a reference for configuring the collection policy for the user.

Further, in some embodiments, the traffic collection rule may be configured based on: if the container flow of any container to be collected exceeds a first preset threshold value, the BPF filtering rule configured for the container to be collected comprises at least one of a designated IP address, a designated port and a designated protocol; and if the counted container flow of any container to be collected does not exceed a second preset threshold, the BPF filtering rule configured for the container to be collected is empty. That is, when the container traffic of any container to be collected exceeds the preset upper limit value in the statistical result of the client, which indicates that the current traffic of the container to be collected is large, a stricter filtering rule may be configured at this time, so that when the client collects the veth-pair virtual network card of the container to be collected, the original traffic may be filtered according to the designated IP address, the designated port, the designated protocol, and the like; and when the container flow of any container to be collected does not exceed a preset lower limit value in the statistical result of the client, the current flow of the container to be collected is small, and at the moment, the corresponding BPF filtering rule can be configured to be empty, so that when the client collects the veth-pair virtual network card of the container to be collected, all types of data packets can be captured. Therefore, the balance between the data acquisition requirement and the bandwidth limitation during container flow detection is met, and the adjusted acquisition strategy is more reasonable. The first preset threshold and the second preset threshold may be set according to the requirements of a specific scenario, which is not limited in this application.

In addition, in practical applications, a user often needs to change the acquisition strategy, and therefore, in some embodiments, the method may further include: when a new acquisition strategy issued by a server is acquired, applying a flow acquisition rule in the new acquisition strategy to acquire container flow of a veth-pair virtual network card of a container to be acquired in the new acquisition strategy. That is, when a user configures a new acquisition policy, such as a new requirement for acquiring container traffic for a certain container, the client replaces the original acquisition policy with the new acquisition policy, and further performs container traffic acquisition according to the new acquisition policy. Therefore, the user can conveniently adjust the acquisition strategy, and the use experience of the user is improved.

In the embodiment of the application, a client deployed on a Linux host acquires an acquisition strategy issued by a server, and according to the acquisition strategy, a veth-pair virtual network card of a container to be acquired is subjected to container flow acquisition on the Linux host, and the acquired container flow is reported to a detection system. Therefore, various container deployment modes are supported, and an independent flow acquisition rule is configured for each container to be acquired, so that the configuration is more flexible and richer, and the standardization and the commercialization are easy.

To illustrate the solution of the present application in more detail, a specific embodiment is described below:

as shown in fig. 2, fig. 2 is a schematic diagram of an overall architecture of a container traffic collection system provided in this embodiment of the present application, where the system includes a Linux host 21, a collection control server 22, and a NIDS23, where three containers, namely a container 1, a container 2, and a container 3 (numbers in the figure are 241, 242, and 243 in sequence), are run on the Linux host 21, and each container has a corresponding veth-pair virtual network card (numbers in the figure are 251, 252, and 253 in sequence) on the Linux host; a collector 26 is also running on the Linux host 21.

Specifically, the workflow of the system for collecting the container flow comprises the following steps:

s201, collecting and controlling the server 22 to collect container asset information, including ID, name, MAC address, IP address, veth-pair virtual network card name, etc. of the container;

there are many methods for collecting and controlling the container asset information by the server 22, including but not limited to obtaining through API, reporting by the collector 26, etc.;

s202, a user configures an acquisition strategy at an acquisition control server 22, wherein the acquisition strategy comprises a container to be acquired, a corresponding BPF filtering rule, a speed limit threshold value and the like;

wherein, the container to be collected can be all or part of the three containers, and different containers can correspond to different BPF filtering rules and also can correspond to different speed limit thresholds;

s203, the acquisition control server 22 issues the acquisition strategy to the acquisition device 26;

s204, the collector 26 collects the path-pair virtual network cards of different containers according to a collection strategy, and different BPF filtering rules, speed limit thresholds and the like are applied;

s205, collector 26 collects the container traffic, then carries out VXLAN/GRE encapsulation, and sends to NIDS23.

As can be seen from the above, the embodiments of the present application provide a general container traffic collection method, where a veth-pair virtual network card of each container is collected on a Linux host, which is supported in various container deployment manners, and a user may configure collection rules with the container as a granularity, for example, setting BPF filtering rules, speed limit thresholds, and the like for collection by a specific container, so that the configuration is more flexible and richer, and is easier to standardize and commercialize.

Corresponding to the embodiments of the foregoing method, the present application further provides embodiments of a container flow collection device and a terminal applied thereto:

as shown in fig. 3, fig. 3 is a block diagram of a container traffic collection apparatus provided in an embodiment of the present application, where the apparatus is applied to a client deployed on a Linux host, where at least one container runs on the Linux host, and the apparatus includes:

the acquisition module 31 is configured to acquire an acquisition policy issued by a server, where the acquisition policy includes a container to be acquired and a corresponding traffic acquisition rule;

the acquisition module 32 is configured to apply a corresponding traffic acquisition rule to perform container traffic acquisition on the veth-pair virtual network card of the container to be acquired according to the acquisition policy;

and a sending module 33, configured to send the collected container flow to the detection system.

The implementation process of the functions and actions of each module in the above device is detailed in the implementation process of the corresponding steps in the above method, and is not described herein again.

Fig. 4 shows a block diagram of an electronic device according to an embodiment of the present disclosure, where fig. 4 is a block diagram of the electronic device. The electronic device may include a processor 410, a communication interface 420, a memory 430, and at least one communication bus 440. Wherein the communication bus 440 is used to enable direct connection communication of these components. In this embodiment, the communication interface 420 of the electronic device is used for performing signaling or data communication with other node devices. The processor 410 may be an integrated circuit chip having signal processing capabilities.

The Processor 410 may be a general-purpose Processor including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components. The various methods, steps, and logic blocks disclosed in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor 410 may be any conventional processor or the like.

The Memory 430 may be, but is not limited to, a Random Access Memory (RAM), a Read Only Memory (ROM), a Programmable Read Only Memory (PROM), an Erasable Read Only Memory (EPROM), an electrically Erasable Read Only Memory (EEPROM), and the like. The memory 430 stores computer readable instructions, and when the computer readable instructions are executed by the processor 410, the electronic device can perform the steps involved in the method embodiment of fig. 1.

Optionally, the electronic device may further include a memory controller, an input output unit.

The memory 430, the memory controller, the processor 410, the peripheral interface, and the input/output unit are electrically connected to each other directly or indirectly to implement data transmission or interaction. For example, these components may be electrically coupled to each other via one or more communication buses 440. The processor 410 is used to execute executable modules stored in the memory 430, such as software functional modules or computer programs included in the electronic device.

The input and output unit is used for providing a task for a user to create and start an optional time period or preset execution time for the task creation so as to realize the interaction between the user and the server. The input/output unit may be, but is not limited to, a mouse, a keyboard, and the like.

It will be appreciated that the configuration shown in fig. 4 is merely illustrative and that the electronic device may include more or fewer components than shown in fig. 4 or may have a different configuration than shown in fig. 4. The components shown in fig. 4 may be implemented in hardware, software, or a combination thereof.

The embodiment of the present application further provides a storage medium, where the storage medium stores instructions, and when the instructions are run on a computer, when the computer program is executed by a processor, the method in the method embodiment is implemented, and in order to avoid repetition, details are not repeated here.

The present application also provides a computer program product which, when run on a computer, causes the computer to perform the method of the method embodiments.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method can be implemented in other ways. The apparatus embodiments described above are merely illustrative, and for example, the flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

In addition, functional modules in the embodiments of the present application may be integrated together to form an independent part, or each module may exist alone, or two or more modules may be integrated to form an independent part.

The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk, and various media capable of storing program codes.

The above description is only an example of the present application and is not intended to limit the scope of the present application, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application shall be included in the protection scope of the present application. It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising a … …" does not exclude the presence of another identical element in a process, method, article, or apparatus that comprises the element.

Claims

1. A container traffic collection method is applied to a client deployed on a Linux host on which at least one container runs, and comprises the following steps:

and sending the collected container flow to a detection system.

2. The method according to claim 1, wherein the collection policy carries container asset information of the container to be collected, and the container asset information includes at least one of the following:

3. The method according to claim 2, wherein the container asset information is obtained by the server through an API provided by a container deployment platform; and/or the container asset information is reported to the server side by the client side.

4. The method according to claim 2, wherein the applying, according to the collection policy, the corresponding traffic collection rule to perform container traffic collection on a veth-pair virtual network card of the container to be collected includes:

determining a path-pair virtual network card of the container to be collected according to the container asset information;

and acquiring the container flow of the path-pair virtual network card by applying a corresponding flow acquisition rule.

5. The method of claim 1, wherein the traffic collection rules comprise at least one of:

BPF filtering rules and speed limit thresholds.

6. The method of claim 5, further comprising:

7. The method of claim 6, wherein the traffic collection rules are configured based on:

8. The method of claim 1, wherein the server provides a configuration interface for a user to configure the acquisition policy.

9. The method of claim 1, wherein sending the collected container flow to a detection system comprises:

10. The method of claim 1, further comprising:

11. A container traffic collection apparatus applied to a client deployed on a Linux host, the Linux host running thereon at least one container, the apparatus comprising:

and the sending module is used for sending the collected container flow to the detection system.

12. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1 to 10.

13. An electronic device, comprising: memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the method according to any of claims 1 to 10 when executing the computer program.