Outlet flow tracking method and device for containerized cluster, medium and equipment

Abstract

The invention relates to the technical field of internet, finance and medical health, and particularly discloses an exit traffic tracking method and device for a containerized cluster, a storage medium and computer equipment. Reading internal address information of a data sending Pod in a containerized cluster from a packet header, converting the internal address information in the packet header into external routable address information of an exit gateway node, embedding the internal address information in the packet header through a user-defined field to obtain an updated exit flow data packet, and sending the updated exit flow data packet to a firewall analysis module; after receiving the updated exit flow data packet, the firewall analysis module forwards the updated exit flow data packet to a data receiving node; and according to the internal address information, the source port information, the target address information and the target port information read from the packet header, generating target log information, and performing exit traffic tracking on each data sending Pod based on the target log information.

Description

Technical Field

[0001] The present application relates to the technical fields of the Internet, finance, and healthcare, and in particular, to a method and apparatus for tracking egress traffic in a containerized cluster, a storage medium, and a computer device. Background Art

[0002] In a containerized cluster (such as a Kubernetes cluster), the network architecture is designed such that each Pod is assigned an independent internal private IP address to enable communication between containers within the cluster. However, when a Pod needs to access the external network, its traffic typically needs to go through an Egress Gateway Node for SNAT (Source Network Address Translation) processing. The role of SNAT is to convert the internal private IP address of the Pod into the external routable IP address of the Egress Gateway Node, thereby achieving network address reuse and traffic management.

[0003] Although SNAT plays a crucial role in containerized clusters, its processing can lead to the loss of the internal private IP addresses of the original Pods. Specifically, the egress traffic after SNAT processing only carries the IP address of the Egress Gateway Node, and the internal private IP addresses of the original Pods cannot be directly passed to the destination address. This information loss poses significant challenges to traffic tracing and troubleshooting in containerized clusters. For example, in the financial system deployed based on containerized clusters in the financial industry (such as a securities trading system deployed using Kubernetes), the financial system usually consists of multiple microservices that run in different Pods. Each Pod communicates with other containers through internal addresses. When accessing external networks (such as exchange interfaces and third-party data service providers) externally, the traffic is processed by the Egress Gateway Node for SNAT. However, due to SNAT of the egress traffic, the internal addresses of the original Pods are lost. When a security incident (such as abnormal traffic attacks or data leaks) is caused by the egress traffic, the security team cannot quickly locate the Pod that initiated the abnormal request, resulting in low efficiency in incident response and troubleshooting, and affecting the security and stability of the financial system. Another example is in the containerized clusters in the healthcare industry (such as a PACS imaging system and an electronic medical record EMR system deployed based on Kubernetes). The network architecture enables communication between containers by assigning independent internal addresses to each Pod. However, when accessing external networks across clusters or externally (such as cloud storage and regional medical collaboration platforms), the egress traffic needs to be processed by the Egress Gateway Node for SNAT. This process directly leads to the loss of the internal address information of the original Pods. When a security incident (such as abnormal traffic attacks or data leaks) is caused by the egress traffic, the administrator cannot quickly locate the source Pod of the egress traffic, resulting in low efficiency in incident response and troubleshooting, and seriously affecting the traffic tracing and security incident response efficiency in the medical scenario. Summary of the Invention

[0004] In view of this, the present application provides a method and device for egress traffic tracing in a containerized cluster, a storage medium, and a computer device. Pods within the containerized cluster and nodes outside the containerized cluster can still communicate through the egress gateway node. Only a firewall parsing module needs to be additionally deployed at the egress gateway node, without modifying the existing network architecture, reducing the implementation complexity, and at the same time achieving fine-grained tracing of egress traffic within the containerized cluster.

[0005] According to one aspect of the present application, there is provided a method for egress traffic tracing in a containerized cluster. The containerized cluster includes an egress gateway node, and a source address conversion module and a firewall parsing module are deployed on the egress gateway node. The method includes:

[0006] When the source address translation module receives an egress traffic data packet, it reads the internal address information of the data sending Pod in the containerized cluster from the header of the egress traffic data packet, converts the internal address information in the header into the external routable address information corresponding to the egress gateway node, embeds the internal address information in the header through a custom field to obtain an updated egress traffic data packet, and sends the updated egress traffic data packet to the firewall parsing module;

[0007] After receiving the updated egress traffic data packet, the firewall parsing module forwards the updated egress traffic data packet to the data receiving node; and generates target log information based on the internal address information, source port information, target address information corresponding to the data receiving node, and target port information read from the header of the updated egress traffic data packet, so as to perform egress traffic tracking on each data sending Pod in the containerized cluster based on the target log information.

[0008] According to another aspect of the present application, there is provided an egress traffic tracking device for a containerized cluster. The containerized cluster includes an egress gateway node, and a source address translation module and a firewall parsing module are deployed on the egress gateway node. The device includes:

[0009] The source address translation module is configured to, when receiving an egress traffic data packet, read the internal address information of the data sending Pod in the containerized cluster from the header of the egress traffic data packet, convert the internal address information in the header into the external routable address information corresponding to the egress gateway node, embed the internal address information in the header through a custom field to obtain an updated egress traffic data packet, and send the updated egress traffic data packet to the firewall parsing module;

[0010] The firewall parsing module is configured to, after receiving the updated egress traffic data packet, forward the updated egress traffic data packet to the data receiving node; and generate target log information based on the internal address information, source port information, target address information corresponding to the data receiving node, and target port information read from the header of the updated egress traffic data packet, so as to perform egress traffic tracking on each data sending Pod in the containerized cluster based on the target log information.

[0011] According to yet another aspect of the present application, there is provided a storage medium, on which a computer program is stored, and when the program is executed by a processor, the above-mentioned egress traffic tracking method for a containerized cluster is implemented.

[0012] According to another aspect of the present application, there is provided a computer device, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor. When the processor executes the program, the above-mentioned method for tracking egress traffic of a containerized cluster is implemented.

[0013] By means of the above technical solution, for a method and device for tracking egress traffic of a containerized cluster, a storage medium, and a computer device provided by the present application, after receiving an egress traffic data packet, the source address conversion module can read the internal address information of the data sending Pod in the containerized cluster from the packet header of the egress traffic data packet. Further, the position of the internal address information in the packet header is replaced with the external routable address information of the egress gateway node. In addition, the source address conversion module can also embed the internal address information into the packet header in the form of a custom field in the packet header, so as to ensure that even after passing through the source address conversion module, the packet header of the egress traffic data packet still carries the internal address information of the data sending Pod. Subsequently, the updated data packet is sent to the firewall parsing module. After receiving the egress traffic data packet sent by the source address conversion module, on the one hand, the firewall parsing module routes the received egress traffic data packet to the data receiving node; on the other hand, it can also parse the packet header of the egress traffic data packet, extract the internal address information of the data sending Pod from the custom field of the packet header, and read the source port information of the data sending Pod, the target address information and target port information of the data receiving node from the remaining positions of the packet header. Then, combining the target address information, target port information, internal address information, source port information, etc., target log information is generated. In the embodiment of the present application, the Pods within the containerized cluster and the nodes outside the containerized cluster can still communicate through the egress gateway node. It only needs to deploy a firewall parsing module additionally at the egress gateway node, without modifying the existing network architecture, reducing the implementation complexity, and at the same time realizing the fine-grained tracking of the egress traffic within the containerized cluster.

[0014] The above description is only an overview of the technical solution of the present application. In order to be able to understand the technical means of the present application more clearly, it can be implemented according to the content of the specification. And in order to make the above and other purposes, features and advantages of the present application more obvious and understandable, the following specific embodiments of the present application are specifically exemplified. Description of the Drawings

[0015] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation of the present application. In the drawings:

[0016] Figure 1 A flowchart showing a method for tracking egress traffic of a containerized cluster provided by an embodiment of the present application is shown;

[0017] Figure 2 Shows a schematic diagram of the internal architecture of a containerized cluster provided by an embodiment of the present application;

[0018] Figure 3 Shows a schematic diagram of the structure of an egress traffic tracking device for a containerized cluster provided by an embodiment of the present application;

[0019] Figure 4 Shows a schematic diagram of the device structure of a computer device provided by an embodiment of the present application. Detailed implementation manners

[0020] The present application will be described in detail below with reference to the accompanying drawings and in conjunction with embodiments. It should be noted that, without conflict, the embodiments in the present application and the features in the embodiments can be combined with each other.

[0021] In this embodiment, an egress traffic tracking method for a containerized cluster is provided. The containerized cluster includes an egress gateway node, and a source address translation module and a firewall parsing module are deployed on the egress gateway node. As Figure 1 shown, the method includes:

[0022] Step 101, when the source address translation module receives an egress traffic data packet, it reads the internal address information of the data sending Pod in the containerized cluster from the header of the egress traffic data packet, converts the internal address information in the header into the external routable address information corresponding to the egress gateway node, and embeds the internal address information in the header through a custom field to obtain an updated egress traffic data packet, and sends the updated egress traffic data packet to the firewall parsing module.

[0023] Step 102, after the firewall parsing module receives the updated egress traffic data packet, it forwards the updated egress traffic data packet to the data receiving node; and generates target log information according to the internal address information, source port information, target address information corresponding to the data receiving node, and target port information read from the header of the updated egress traffic data packet, so as to perform egress traffic tracking on each data sending Pod in the containerized cluster based on the target log information.

[0024] In a containerized cluster (such as Kubernetes), the internal address of a Pod (such as an IP address) is a virtual address allocated within the cluster (such as 10.x.x.x), which cannot be directly recognized by the external network. When the egress traffic of a Pod flows out through an egress gateway node (such as Ingress / Egress Gateway), the source network address translation (SNAT) is required to replace the internal address of the Pod with the externally routable address of the egress gateway node (such as a public IP) to ensure that the egress traffic can be received externally. However, this conversion process makes it difficult to trace the egress traffic: the external system can only see the externally routable address information of the egress gateway node and cannot associate it with a specific Pod inside the cluster, increasing the complexity of security auditing, fault troubleshooting, and traffic monitoring. Based on this, the embodiments of this application provide an egress traffic tracing method that can be applied to a containerized cluster. In this containerized cluster, an egress gateway node can be set up, and traffic tracing is implemented through two core modules (source network address translation module, firewall parsing module) deployed on the egress gateway node. The source network address translation module configured on the egress gateway node can ensure that all egress traffic passes through the source network address translation module for processing.

[0025] Specifically, after receiving an egress traffic data packet, the source network address translation module can read the internal address information of the data sending Pod in the containerized cluster from the header of the egress traffic data packet. Here, each egress traffic data packet corresponds to a data sending Pod and a data receiving node. The data sending Pod is a Pod in the containerized cluster, and the data receiving node is a node outside the containerized cluster. After the source network address translation module reads the internal address information of the data sending Pod, further, the position of the internal address information in the header is replaced with the externally routable address information of the egress gateway node. Here, the externally routable address is an address that can be routed to by a node outside the containerized cluster. In addition, the source network address translation module is also configured with an additional function, that is, after reading the internal address information of the data sending Pod from the header, the internal address information can be embedded into the header in the form of a custom field in the header to ensure that the egress traffic data packet still carries the internal address information of the data sending Pod even after passing through the source network address translation module. It should be noted that after the source network address translation module reads the internal address information of the data sending Pod from the header of the egress traffic data packet, the two steps of address replacement and embedding can be carried out simultaneously. Subsequently, the updated data packet is sent to the firewall parsing module.

[0026] After the firewall parsing module receives the egress traffic data packet sent by the source address translation module, on the one hand, it routes the received egress traffic data packet to the data receiving node (such as cloud service, public network server); on the other hand, it can also parse the header of the egress traffic data packet, extract the internal address information of the data sending Pod (such as 10.244.1.5:8080) from the custom field of the header, and read the source port information of the data sending Pod, the target address information of the data receiving node (such as 203.0.113.45:443), and the target port information from the remaining positions of the header. Then, combining the target address information, target port information, internal address information, source port information, etc., it generates the target log information. In this way, every time an egress traffic data packet is sent outside the containerized cluster, it is recorded by the firewall parsing module. Subsequently, the egress traffic of each data sending Pod in the containerized cluster can be traced based on the target log information. For example, tracing which data sending Pods access external sensitive services to identify abnormal traffic; counting the egress traffic distribution by dimensions such as data sending Pods to optimize resource allocation, etc. In addition, the data receiving node can also parse the internal address information of the data sending Pod from the header of the egress traffic data packet, so as to quickly perform fault troubleshooting and location, enhance security, etc. For example, if the data receiving node (such as external API service, cloud database) has an exception (such as connection timeout, response error), the data receiving node can directly obtain the internal address information of the data sending Pod from the custom field of the header of the egress traffic data packet, and can immediately locate the problem Pod, shortening the fault recovery time. Another example is that if the data receiving node is a security device (such as WAF, IDS), it can directly obtain the internal address information of the data sending Pod from the custom field of the header of the egress traffic data packet, and combine the threat intelligence library (such as known malicious IP list) to block the traffic from high-risk Pods in real time.

[0027] In a specific embodiment, many current large-scale medical and health platforms launch medical microservices (such as electronic medical record system, AI image analysis) which are all implemented through containerized clusters. For example, for the medical microservice of AI image analysis, when a certain department (data sending Pod) sends data externally, when the egress gateway node in the corresponding containerized cluster of this medical microservice forwards these data, it can additionally embed the internal address information of the data sending Pod to which this department belongs in the header through a custom field, so as to achieve second-level tracing to the specific data sending Pod (department) in case of data leakage, effectively improving the operation and maintenance efficiency and security of large-scale medical and health platforms.

[0028] In another specific embodiment, a large financial platform deploys intelligent risk control microservices (such as anti-fraud analysis and real-time transaction monitoring) through a containerized cluster. One of the business departments (data sending Pod) needs to transmit customer transaction data externally to a third-party credit investigation agency. Therefore, when this business department forwards data through the egress gateway node (EgressGateway) of the containerized cluster, it can embed the internal address information of this business department (data sending Pod) in the packet header through a custom protocol field. In this way, if the third-party credit investigation agency feedbacks that there is a risk of data leakage, the financial platform can quickly locate the specific business department by parsing the custom field of the data packet header and quickly initiate an emergency response (such as blocking transmission and auditing logs), significantly improving the efficiency and security of financial data security control.

[0029] By applying the technical solution of this embodiment, after receiving the egress traffic data packet, the source address conversion module can read the internal address information of the data sending Pod in the containerized cluster from the packet header of the egress traffic data packet. Further, the position of the internal address information in the packet header is replaced with the external routable address information of the egress gateway node. In addition, the source address conversion module can also embed the internal address information into the packet header in the form of a custom field in the packet header to ensure that even after passing through the source address conversion module, the packet header of the egress traffic data packet still carries the internal address information of the data sending Pod. Subsequently, the updated data packet is sent to the firewall parsing module. After receiving the egress traffic data packet sent by the source address conversion module, on the one hand, the firewall parsing module routes the received egress traffic data packet to the data receiving node; on the other hand, it can also parse the packet header of the egress traffic data packet, extract the internal address information of the data sending Pod from the custom field of the packet header, and read the source port information of the data sending Pod, the target address information and target port information of the data receiving node from the remaining positions of the packet header. Then, combined with the target address information, target port information, internal address information, source port information, etc., target log information is generated. In the embodiment of the present application, the Pod within the containerized cluster and the node outside the containerized cluster can still communicate through the egress gateway node. Only a firewall parsing module needs to be additionally deployed at the egress gateway node, without modifying the existing network architecture, reducing the implementation complexity, and at the same time realizing the refined tracking of the egress traffic within the containerized cluster.

[0030] In an embodiment of the present application, optionally, in step 101, the "embedding the internal address information into the packet header through a custom field to obtain an updated egress traffic packet" includes: parsing the egress traffic packet to determine the standard protocol included in the egress traffic data, and determining the target embedding position of the custom field in the packet header according to the type of the standard protocol; adding the internal address information to the custom field, and embedding the custom field after addition into the target embedding position of the packet header to obtain an updated egress traffic packet.

[0031] In this embodiment, it is assumed that a financial institution deploys a payment risk control system through a containerized cluster and needs to transmit customer transaction flow data to an external cooperative bank. To meet the traffic audit requirements, when transmitting customer transaction flow data to the external cooperative bank, the internal address information of the data sending Pod can be embedded into the egress traffic packet while ensuring that the standard protocol compatibility is not damaged. Specifically, the internal address information of the data sending Pod can be embedded in the following manner: First, parse the egress traffic packet to identify the type of the standard protocol it contains. Specifically, a protocol parser can be used to identify the standard protocol used by the egress traffic packet (such as TCP / IP, UDP, HTTP, etc.). Subsequently, according to different protocol types, determine the best embedding position of the custom field in the packet header. Here, the protocol types of the standard protocol can include IPv4, IPv6, etc. For different protocol types, the embedding positions corresponding to each protocol type can be preset. For example, for IPv4, the IP option field, unused flag bit, or extension header can be selected as the target embedding position; for IPv6, the extension header (such as the hop-by-hop option header, destination option header) can be used as the target embedding position; for transport layer protocols (TCP / UDP), the unused port number range or custom option field can be used as the target embedding position; for application layer protocols (HTTP), the custom header field can be used as the target embedding position.

[0032] Next, add the internal address information of the data sending Pod to the custom field, and insert the custom field containing the internal address information into the previously determined target embedding position, thereby generating an updated egress traffic packet. The embodiment of the present application can realize the transmission of custom information by utilizing the extensible part in the standard protocol without damaging the standard protocol compatibility.

[0033] In an embodiment of the present application, optionally, a configuration module is further deployed on the egress gateway node; before the "source address translation module receives the egress traffic data packet" in step 101, the method further includes: the configuration module configures an identity retention mechanism in the source address translation module based on a configuration instruction, and establishes a communication connection between the output end of the source address translation module and the input end of the firewall parsing module, so that the source address translation module embeds the internal address information of the data sending Pod in the packet header of the egress traffic data packet based on the identity retention mechanism, and enables the firewall parsing module to execute the step of generating target log information based on the updated egress traffic data packet.

[0034] In this embodiment, a configuration module can also be deployed on the egress gateway node to dynamically configure the cooperation logic between the source address translation module and the firewall parsing module. Specifically, the configuration module can receive the configuration instruction of the administrator and configure an identity retention mechanism in the source address translation module based on this configuration instruction (such as through CONNMARK of Netfilter or a custom data packet extension field). Here, the identity retention mechanism can ensure that after the source address translation module reads the internal address information of the data sending Pod, under the trigger of the internal address information, it embeds the internal address information of the data sending Pod in the packet header of the egress traffic data packet through a custom field. In addition, a logical channel can be established between the output end of the source address translation module and the input end of the firewall parsing module (such as a Linux netlink socket or a Kafka message queue), so that the firewall parsing module can execute step 102, that is, generate target log information, after receiving the egress traffic data packet. For example, a certain securities institution deploys a trading risk control system using a containerized cluster, and this trading risk control system needs to transmit real-time trading data to an external regulatory agency. To meet the requirements of egress traffic auditing, the internal address information of the data sending Pod is embedded in the egress traffic data packet to achieve traceability of the egress traffic data packet. Therefore, the cooperation logic between the source address translation module and the firewall parsing module can be dynamically configured through the configuration module deployed on the egress gateway node, realizing the linkage between the source address translation module and the firewall parsing module. Furthermore, the source address translation module embeds the internal address information of the data sending Pod into the egress traffic data packet, and the firewall parsing module generates target log information that can be used for security event tracing.

[0035] In an embodiment of the present application, optionally, after step 102, the method further includes: the firewall parsing module calls the application programming interface corresponding to the containerized cluster, and through the application programming interface, obtains the target information corresponding to each Pod in the containerized cluster, where the target information includes the Pod name, the Pod namespace, and the internal address information; the firewall parsing module determines the target Pod name and the target Pod namespace corresponding to the data sending Pod according to the internal address information of the data sending Pod and the target information corresponding to each Pod, and associates the target Pod name and the target Pod namespace with the target log information.

[0036] In this embodiment, when parsing the egress traffic data packet, the firewall parsing module can only obtain the internal address information of the data sending Pod, but the internal address information itself is not intuitive to the operation and maintenance personnel. Therefore, by calling the API (Application Programming Interface) of the containerized cluster, the firewall parsing module can query the Pod name (such as emr-service-7b8f9d6c9) and the namespace (such as hospital-ns) corresponding to the internal address information of the data sending Pod, and supplement the target log information of the data sending Pod according to this information. Specifically, the firewall parsing module can extract the internal address information of the data sending Pod from the egress traffic data packet, and call the API of the containerized cluster to query the target information of all Pods. Here, the target information can include the Pod name, the Pod namespace, the internal address information, etc. Then, according to the internal address information of the data sending Pod, the target Pod name and the target Pod namespace of the data sending Pod are matched from the above-mentioned target information corresponding to the Pod, and these information are associated with the target log information of the data sending Pod, so as to improve the readability, traceability ability and operation and maintenance efficiency of the target log.

[0037] For example, a certain hospital uses Kubernetes (K8s) as a containerization platform, on which multiple medical microservices (such as PACS imaging system, EMR electronic medical record system) are deployed. Among them, a Pod is the smallest deployment unit in K8s. Specifically, the pacs-storage-pod is a Pod for storing medical images (such as CT, MRI); the pacs-api-pod is a Pod for providing image query interfaces; the emr-frontend-pod is a front-end service Pod for doctors to access medical records. Suppose the data sending Pod of the egress traffic data packet is the Pod for storing medical images (such as CT, MRI). Then, the application programming interface of the containerized cluster can be called to obtain the target information of all Pods currently including pacs-storage-pod, pacs-api-pod, and emr-frontend-pod, and match the target information of these Pods with the internal address information of the data sending Pod. After matching, it is found that the internal address information of the pacs-storage-pod is consistent with the internal address information of the data sending Pod. Then, the Pod name and Pod namespace of the pacs-storage-pod can be used as the target Pod name and target Pod namespace.

[0038] In an embodiment of the present application, optionally, the containerized cluster further includes an audit report generation module; after "associating the target Pod name and the target Pod namespace with the target log information", the audit report generation module performs the following steps: receiving a traffic audit report generation instruction, based on the traffic audit report generation instruction, obtaining traffic audit report requirement information, and calling a preset parsing model to parse the traffic audit report requirement information to obtain at least one target traffic audit indicator; for each target traffic audit indicator, calling an analysis tool corresponding to the target traffic audit indicator, and analyzing the associated target log information through the analysis tool to obtain a traffic audit result corresponding to the target traffic audit indicator; generating a traffic audit report according to the traffic audit results corresponding to each target traffic audit indicator.

[0039] In this embodiment, on the basis of associating the target log information with the target Pod name and the target Pod namespace, further, a traffic audit report can be automatically generated by an audit report generation module. This module supports parsing audit requirements on demand, calling corresponding analysis tools to generate indexed results, and finally outputting a structured report. Specifically, a user (such as a security administrator) can issue a traffic audit report generation instruction through an interface or an API. Then, based on this traffic audit report generation instruction, traffic audit report requirement information can be obtained. For example, if a hospital needs to regularly audit the situation of the PACS imaging system sending data externally to prevent the leakage of medical imaging data, then the traffic audit report requirement information can be: generate an egress traffic audit report of the PACS imaging system in the past 24 hours. Subsequently, the audit report generation module calls a preset parsing model (such as an NLP model or a rule engine) to extract target traffic audit metrics from the traffic audit report requirement information. For example: Metric 1: Number of external accesses; Metric 2: Concentration of external accesses. Further, for each target traffic audit metric, a corresponding analysis tool (such as Elasticsearch aggregation query, Splunk statistical script) is called to process the associated target log information to obtain the traffic audit result corresponding to the target traffic audit metric. When the traffic audit results of all target traffic audit metrics are analyzed, a traffic audit report can be generated based on these traffic audit results.

[0040] In an embodiment of the present application, optionally, before "generating a traffic audit report according to the traffic audit results corresponding to each target traffic audit metric", the method further includes: the audit report generation module determines the service type corresponding to the containerized cluster, and based on the service type, obtains initial traffic audit metrics from a target website. For each initial traffic audit metric, a reliability value of the initial traffic audit metric is calculated through a preset reliability model, and when the reliability value is greater than a preset threshold, the initial traffic audit metric is used as a supplementary traffic audit metric; correspondingly, "generating a traffic audit report according to the traffic audit results corresponding to each target traffic audit metric" includes: calculating the traffic audit results corresponding to each supplementary traffic audit metric, generating a traffic audit basic report according to the traffic audit results corresponding to each target traffic audit metric, and generating a traffic audit supplementary report according to the traffic audit results corresponding to each supplementary traffic audit metric.

[0041] In this embodiment, before generating the traffic audit report, the comprehensiveness and reliability of the report can also be enhanced through a dynamic supplementary index mechanism. Specifically, the audit report generation module can identify the business types of the containerized cluster (such as medical imaging systems, electronic medical record systems). For example, if the containerized cluster runs a PACS imaging system, the service type can be medical-imaging. Then, the initial traffic audit metrics can be obtained from the target website according to the service type. For example, pull the initial traffic audit metrics related to medical-imaging from the target website (such as the medical industry standard library). Here, the initial traffic audit metrics can include image upload latency (industry standard requirement ≤ 500ms), cross-region access frequency (such as the scenario of mutual recognition of images in different branches), etc. Further, the reliability of each initial traffic audit metric is evaluated through a preset reliability model (such as a scoring model verified based on historical data). In a specific embodiment, the reliability can include the generality of the initial traffic audit metric in the medical industry (such as whether it is recommended by HIPAA), the relevance of the initial traffic audit metric to the current service type (such as the importance of image upload latency to the PACS imaging system), etc. Only when the reliability value of the initial traffic audit metric is greater than the preset threshold (such as 0.8), will it be used as a supplementary traffic audit metric. For example, image upload latency (reliability value 0.95) → retained as a supplementary traffic audit metric; cross-region access frequency (reliability value 0.6) → excluded. After determining the supplementary traffic audit metrics, the traffic audit results corresponding to each supplementary traffic audit metric can be calculated using the same method as the target traffic audit metrics.

[0042] Finally, a dual report including a traffic audit basic report and a traffic audit supplementary report is generated. Among them, the traffic audit basic report is generated based on the target traffic audit metrics of the user's original requirements; the traffic audit supplementary report is generated based on the dynamically screened supplementary traffic audit metrics.

[0043] In the embodiment of the present application, optionally, the preset reliability model includes a first feature extraction model, a second feature extraction model, and a comparison model; the "calculating the reliability value of the initial traffic audit metric through the preset reliability model" includes: obtaining the description file corresponding to the service type, and the target network structure corresponding to the initial traffic audit metric, where the target network structure is constructed based on the usage of the initial traffic audit metric; based on the description file, extracting the file features corresponding to the description file through the first feature extraction model; based on the target network structure, extracting the metric features corresponding to the initial traffic audit metric through the second feature extraction model; calculating the feature matching degree between the file features and the metric features through the comparison model, and determining the reliability value of the initial traffic audit metric based on the feature matching degree.

[0044] In this embodiment, the preset reliability model includes a first feature extraction model, a second feature extraction model, and a comparison model. Among them, the first feature extraction model is used to analyze the description file of the service type (such as the business scenario document of the PACS imaging system) and extract text features (such as keywords, context semantics). The second feature extraction model is used to analyze the target network structure of the initial traffic audit metrics and extract structural features. The target network structure can be a network structure constructed based on information such as the usage frequency and relevance of the initial traffic audit metrics in historical projects. The comparison model is used to calculate the feature matching degree of the two types of features and output a reliability value (0-1).

[0045] Specifically, first, the descriptive file corresponding to the service type and the target network structure corresponding to the initial traffic audit metrics can be obtained. The descriptive file can be a detailed description of the service type (for example, the PACS imaging system of medical-imaging needs to support the DICOM protocol); the target network structure can be constructed based on the usage of the initial traffic audit metrics in historical projects (for example, the image upload delay has been used in 10 medical projects). Then, the descriptive file is parsed by the first feature extraction model (such as an NLP model) to extract keywords and semantic features. For example, keywords DICOM, image storage, and cross-department access are extracted from the description file of the PACS imaging system. The second feature extraction model (such as a graph neural network) can also be used to analyze the target network structure and extract features such as the usage frequency and relevance of the initial traffic audit metrics. For example, the usage frequency of the image upload delay in historical projects is 8 / 10 (80% of the projects involve this metric). Subsequently, the feature matching degree of the file features and the metric features is calculated by the comparison model (such as the cosine similarity algorithm), and the final reliability value is determined based on this feature matching degree. For example, if the feature matching degree between the image upload delay and the medical-imaging description file is 0.92, then 0.92 can be used as the reliability value of this initial traffic audit metric.

[0046] In the embodiment of the present application, by dynamically extracting file features from the service type description file and combining the historical usage of the metrics, accurate matching between the metrics and the business scenario can be achieved, avoiding metric omission or redundancy caused by insufficient manual experience, and improving the pertinence of the audit report.

[0047] Further, as a refinement and extension of the specific implementation manner of the above embodiment, in order to fully illustrate the specific implementation process of this embodiment, another method for tracking the egress traffic of a containerized cluster is provided, which is implemented based on the containerized cluster as shown in Figure 2 and includes:

[0048] After a data - sending Pod within a containerized cluster sends an egress traffic data packet to a data - receiving node outside the cluster, it needs to pass through an egress gateway node within the cluster. A source - address translation module and a firewall parsing module are deployed on this egress gateway node. Specifically, the source - address translation module receives the egress traffic data packet, converts the internal address information of the data - sending Pod in the packet header of the egress traffic data packet into the external routable address information corresponding to the egress gateway node, and embeds the internal address information of the data - sending Pod in the packet header through a custom field. In this way, an updated egress traffic data packet is obtained. Then, the updated egress traffic data packet is sent to the firewall parsing module. The firewall parsing module, on the one hand, forwards the updated egress traffic data packet to the data - receiving node outside the cluster, and on the other hand, generates target log information based on the updated egress traffic data packet. After generating the target log information, the firewall parsing module can also call the application programming interface of the containerized cluster to supplement the target log information. These information are finally stored by the firewall parsing module in the log system within the cluster.

[0049] Further, as Figure 1 a specific implementation of the method, an embodiment of the present application provides an egress traffic tracking device for a containerized cluster. The containerized cluster includes an egress gateway node, and a source - address translation module and a firewall parsing module are deployed on the egress gateway node. As Figure 3 shown, the device includes:

[0050] The source - address translation module is configured to, when receiving an egress traffic data packet, read the internal address information of the data - sending Pod in the containerized cluster from the packet header of the egress traffic data packet, convert the internal address information in the packet header into the external routable address information corresponding to the egress gateway node, and embed the internal address information in the packet header through a custom field to obtain an updated egress traffic data packet, and send the updated egress traffic data packet to the firewall parsing module;

[0051] The firewall parsing module is configured to, after receiving the updated egress traffic data packet, forward the updated egress traffic data packet to the data - receiving node; and generate target log information according to the internal address information, source port information, target address information corresponding to the data - receiving node, and target port information read from the packet header of the updated egress traffic data packet, so as to perform egress traffic tracking on each data - sending Pod in the containerized cluster based on the target log information.

[0052] Optionally, the source - address translation module is further configured to:

[0053] Parse the egress traffic data packet, determine the standard protocol included in the egress traffic data, and determine the target embedding position of the custom field in the packet header according to the type of the standard protocol;

[0054] Add the internal address information to the custom field, and embed the updated custom field into the target embedding position of the packet header to obtain an updated egress traffic data packet.

[0055] Optionally, a configuration module is further deployed on the egress gateway node; the configuration module is used for:

[0056] Before the source address translation module receives the egress traffic data packet, based on a configuration instruction, configure an identity retention mechanism in the source address translation module, and establish a communication connection between the output end of the source address translation module and the input end of the firewall parsing module, so that the source address translation module executes the step of embedding the internal address information of the data sending Pod in the packet header based on the identity retention mechanism, and enables the firewall parsing module to execute the step of generating target log information based on the updated egress traffic data packet.

[0057] Optionally, the firewall parsing module is further used for:

[0058] After generating the target log information, call the application programming interface corresponding to the containerized cluster, and through the application programming interface, obtain the target information corresponding to each Pod in the containerized cluster, where the target information includes the Pod name, the Pod namespace, and the internal address information;

[0059] According to the internal address information of the data sending Pod and the target information corresponding to each Pod, determine the target Pod name and the target Pod namespace corresponding to the data sending Pod, and associate the target Pod name and the target Pod namespace with the target log information.

[0060] Optionally, the containerized cluster further includes an audit report generation module; the audit report generation module is used for:

[0061] After associating the target Pod name and the target Pod namespace with the target log information, receive a traffic audit report generation instruction, based on the traffic audit report generation instruction, obtain traffic audit report requirement information, and call a preset parsing model to parse the traffic audit report requirement information to obtain at least one target traffic audit indicator;

[0062] For each target traffic audit metric, call the analysis tool corresponding to the target traffic audit metric, and analyze the associated target log information through the analysis tool to obtain a traffic audit result corresponding to the target traffic audit metric;

[0063] Generate a traffic audit report based on the traffic audit results corresponding to each target traffic audit metric.

[0064] Optionally, the audit report generation module is further configured to:

[0065] Before generating the traffic audit report based on the traffic audit results corresponding to each target traffic audit metric, determine the service type corresponding to the containerized cluster, and based on the service type, obtain initial traffic audit metrics from a target website. For each initial traffic audit metric, calculate the reliability value of the initial traffic audit metric through a preset reliability model, and when the reliability value is greater than a preset threshold, use the initial traffic audit metric as a supplementary traffic audit metric;

[0066] Correspondingly, the audit report generation module is further configured to:

[0067] Calculate the traffic audit results corresponding to each supplementary traffic audit metric, generate a traffic audit basic report based on the traffic audit results corresponding to each target traffic audit metric, and generate a traffic audit supplementary report based on the traffic audit results corresponding to each supplementary traffic audit metric.

[0068] Optionally, the preset reliability model includes a first feature extraction model, a second feature extraction model, and a comparison model; the audit report generation module is further configured to:

[0069] Obtain the description file corresponding to the service type and the target network structure corresponding to the initial traffic audit metric, where the target network structure is constructed based on the usage of the initial traffic audit metric;

[0070] Based on the description file, extract the file features corresponding to the description file through the first feature extraction model;

[0071] Based on the target network structure, extract the metric features corresponding to the initial traffic audit metric through the second feature extraction model;

[0072] Calculate the feature matching degree between the file features and the metric features through the comparison model, and determine the reliability value of the initial traffic audit metric based on the feature matching degree.

[0073] It should be noted that for other corresponding descriptions of each functional unit involved in an egress traffic tracking device for a containerized cluster provided in an embodiment of the present application, reference can be made toFigures 1 to 2 The corresponding description in the method will not be elaborated here.

[0074] The embodiments of the present application further provide a computer device, which may specifically be a personal computer, a server, a network device, etc. For example, Figure 4 As shown, the computer device includes a bus, a processor, a memory, and a communication interface, and may further include an input / output interface and a display device. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store location information. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, it implements the steps in the method embodiments.

[0075] Those skilled in the art can understand that Figure 4 the structure shown in is only a block diagram of some structures related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine some components, or have different component arrangements.

[0076] In one embodiment, a computer-readable storage medium is provided. The computer-readable storage medium may be non-volatile or volatile, and stores a computer program. When the computer program is executed by the processor, it implements the steps in the above method embodiments.

[0077] In one embodiment, a computer program product is provided, including a computer program. When the computer program is executed by the processor, it implements the steps in the above method embodiments.

[0078] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or fully authorized by all parties.

[0079] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, database, or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memories. Non-volatile memories can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memories can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The databases involved in the embodiments provided in the present application can include at least one of relational databases and non-relational databases. Non-relational databases can include distributed databases based on blockchain, etc., without limitation. The processors involved in the embodiments provided in the present application can be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, data processing logics based on quantum computing, etc., without limitation.

[0080] The technical features of the above embodiments can be combined arbitrarily. For the sake of concise description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope recorded in this specification.

[0081] The above-described embodiments only represent several implementation manners of the present application. The description is relatively specific and detailed, but it should not be construed as a limitation on the patent scope of the present application. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.

Claims

1. An egress traffic tracing method for a containerized cluster, characterized in that, The containerized cluster includes an egress gateway node, and a source address translation module and a firewall parsing module are deployed on the egress gateway node. The method includes: When receiving an egress traffic data packet, the source address translation module reads the internal address information of the data sending Pod in the containerized cluster from the packet header of the egress traffic data packet, converts the internal address information in the packet header into the external routable address information corresponding to the egress gateway node, and embeds the internal address information in the packet header through a custom field to obtain an updated egress traffic data packet, and sends the updated egress traffic data packet to the firewall parsing module; After receiving the updated egress traffic data packet, the firewall parsing module forwards the updated egress traffic data packet to the data receiving node; and generates target log information based on the internal address information, source port information, target address information and target port information corresponding to the data receiving node read from the packet header of the updated egress traffic data packet, so as to perform egress traffic tracing on each data sending Pod in the containerized cluster based on the target log information.

2. The method according to claim 1, characterized in that, The step of embedding the internal address information in the packet header through a custom field to obtain an updated egress traffic data packet includes: Parsing the egress traffic data packet to determine the standard protocol included in the egress traffic data, and determining the target embedding position of the custom field in the packet header according to the type of the standard protocol; Adding the internal address information to the custom field, and embedding the added custom field in the target embedding position of the packet header to obtain an updated egress traffic data packet.

3. The method according to claim 1, wherein A configuration module is also deployed on the egress gateway node; before the source address translation module receives an egress traffic data packet, the method further includes: Based on a configuration instruction, the configuration module configures an identity retention mechanism in the source address translation module, and establishes a communication connection between the output end of the source address translation module and the input end of the firewall parsing module, so that the source address translation module performs the step of embedding the internal address information of the data sending Pod in the packet header of the egress traffic data packet based on the identity retention mechanism, and enables the firewall parsing module to perform the step of generating target log information based on the updated egress traffic data packet.

4. The method according to claim 1, wherein After generating the target log information, the method further includes: The firewall parsing module calls the application programming interface corresponding to the containerized cluster, and through the application programming interface, obtains the target information corresponding to each Pod in the containerized cluster, where the target information includes the Pod name, Pod namespace and internal address information; The firewall parsing module determines the target Pod name and target Pod namespace corresponding to the data sending Pod according to the internal address information of the data sending Pod and the target information corresponding to each Pod, and associates the target Pod name and the target Pod namespace with the target log information.

5. The method according to claim 4, characterized in that The containerized cluster further includes an audit report generation module; after associating the target Pod name and the target Pod namespace with the target log information, the audit report generation module performs the following steps: Receiving a traffic audit report generation instruction, based on the traffic audit report generation instruction, obtaining traffic audit report requirement information, and invoking a preset parsing model to parse the traffic audit report requirement information to obtain at least one target traffic audit indicator; For each target traffic audit indicator, invoking an analysis tool corresponding to the target traffic audit indicator, and analyzing the associated target log information through the analysis tool to obtain a traffic audit result corresponding to the target traffic audit indicator; Generating a traffic audit report according to the traffic audit results corresponding to the respective target traffic audit indicators.

6. The method according to claim 5, wherein Before generating a traffic audit report according to the traffic audit results corresponding to the respective target traffic audit indicators, the method further includes: The audit report generation module determines the service type corresponding to the containerized cluster, and based on the service type, obtains initial traffic audit indicators from a target website. For each initial traffic audit indicator, calculating a reliability value of the initial traffic audit indicator through a preset reliability model, and when the reliability value is greater than a preset threshold, using the initial traffic audit indicator as a supplementary traffic audit indicator; Correspondingly, generating a traffic audit report according to the traffic audit results corresponding to the respective target traffic audit indicators includes: Calculating the traffic audit results corresponding to the respective supplementary traffic audit indicators, generating a traffic audit basic report according to the traffic audit results corresponding to the respective target traffic audit indicators, and generating a traffic audit supplementary report according to the traffic audit results corresponding to the respective supplementary traffic audit indicators.

7. The method according to claim 6, wherein The preset reliability model includes a first feature extraction model, a second feature extraction model, and a comparison model; calculating the reliability value of the initial traffic audit indicator through the preset reliability model includes: Obtaining a description file corresponding to the service type and a target network structure corresponding to the initial traffic audit indicator, where the target network structure is constructed based on the usage situation of the initial traffic audit indicator; Based on the description file, extracting file features corresponding to the description file through the first feature extraction model; Based on the target network structure, extracting indicator features corresponding to the initial traffic audit indicator through the second feature extraction model; Calculating a feature matching degree between the file features and the indicator features through the comparison model, and determining the reliability value of the initial traffic audit indicator based on the feature matching degree.

8. An egress traffic tracking device for a containerized cluster, characterized in that, The containerized cluster includes an egress gateway node, and a source address translation module and a firewall parsing module are deployed on the egress gateway node. The device includes: The source address conversion module is configured to, when receiving an egress traffic data packet, read the internal address information of the data sending Pod in the containerized cluster from the header of the egress traffic data packet, convert the internal address information in the header into the external routable address information corresponding to the egress gateway node, embed the internal address information in the header through a custom field, obtain an updated egress traffic data packet, and send the updated egress traffic data packet to the firewall parsing module; The firewall parsing module is configured to, after receiving the updated egress traffic data packet, forward the updated egress traffic data packet to the data receiving node; and generate target log information based on the internal address information, source port information, target address information corresponding to the data receiving node, and target port information read from the header of the updated egress traffic data packet, so as to perform egress traffic tracking on each data sending Pod in the containerized cluster based on the target log information.

9. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 7.

10. A computer device, comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 7.

Images