Cloud native-oriented topology adaptive obfuscation method and system

Abstract

The invention discloses a cloud native-oriented topology adaptive confusion method and system, solves the problem that an attacker can obtain a real call topology between services by analyzing flow metadata so as to identify a critical path and a core service in the prior art, and realizes forged flow which is completely harmless to the service and effectively hides the core service. The method comprises the following steps: acquiring flow metadata in real time according to a fixed time interval, and cleaning the flow metadata to obtain a service flow diagram; determining the weight of each feature of the original traffic in each node of the service flow diagram based on the user demand to obtain an initial weighted undirected graph; calculating a composite weight between adjacent nodes in the initial weighted undirected graph to obtain a weighted undirected graph, and performing path calculation on the weighted undirected graph based on a DAG algorithm to obtain a key path; and generating a critical path confusion strategy by using the confusion agent and the filter, and confusing the critical path according to the critical path confusion strategy to obtain a weighted undirected graph after confusion.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to a topology adaptive obfuscation method and system for cloud-native computing. Background Technology

[0002] With the increasing popularity of cloud computing technology, microservice architecture has become the de facto standard for building modern, scalable, and highly resilient applications. By decoupling large monolithic applications into a series of microservices focused on specific business functions and capable of being developed, deployed, and run independently, enterprises gain unprecedented development agility and deployment flexibility.

[0003] However, this architectural shift also introduces a new security risk: function calls that were originally within a monolithic application are now transformed into remote communication across the network. This not only significantly increases system complexity but also transforms the inter-service communication network itself into a vast attack surface that must be rigorously guarded against. To address this challenge, the industry commonly employs transport layer encryption (such as mTLS) to ensure data confidentiality and uses inter-service access control to restrict unauthorized access. While these measures are crucial, they primarily protect the content of communications and access permissions, neglecting a more insidious threat: the communication topology between services can itself serve as an exploitable side channel. Even if attackers gain internal network access but cannot decrypt the traffic content, they can still conduct advanced reconnaissance by passively listening to traffic metadata (such as the number of service dependencies, response latency, and error rates). By analyzing these traffic patterns, attackers can reverse engineer the entire application's service call graph, thereby identifying the most critical call chains and the "crown jewel" services carrying core business logic (e.g., payment services, user authentication centers). Once these critical nodes are accurately located, attackers can launch highly efficient and devastating attacks, such as targeted denial-of-service attacks or data penetration, inflicting fatal damage on the entire system.

[0004] Currently, in microservice architectures, the mainstream solutions for addressing cybersecurity threats mainly focus on: The first type is transport layer encryption, such as bidirectional TLS (Transport Layer Security) implemented through a service mesh. It performs end-to-end encryption of data content during inter-service communication, ensuring the confidentiality and integrity of the data.

[0005] The second type is access control, which restricts the access permissions between services and prevents unauthorized requests by defining fine-grained network policies and authentication mechanisms.

[0006] While the aforementioned solutions are crucial for ensuring the security of microservice communication, they primarily focus on protecting "communication content" and "communication permissions," neglecting the more covert "communication behavior patterns." Even if a request is fully encrypted and legitimately authorized, the fact that it was sent (including metadata such as the source service, target service, number of service dependencies, and response latency) remains visible. Attackers exploit this visible traffic metadata to conduct topology reconnaissance.

[0007] Current mainstream security mechanisms lack the ability to proactively deceive and mislead attackers. They cannot prevent attackers from observing the actual communication topology between microservices, making microservice applications virtually transparent to covert reconnaissance activities. In dynamic and complex microservice environments, features such as service autoscaling, canary deployment, and dynamic routing leave analyzable traffic fingerprints on the network, which in turn helps attackers build more accurate topology models. This situation exposes a huge "reconnaissance defense gap" in existing defense systems, namely the lack of effective defense against reconnaissance attacks based on behavioral pattern analysis, severely weakening the defense-in-depth capabilities of cloud-native applications against advanced persistent threats.

[0008] Existing traffic obfuscation solutions (such as traditional VPN traffic obfuscation) mainly focus on protocol spoofing, traffic shaping, or flooding to bypass network censorship or enhance anonymity. However, they generally lack the ability to dynamically perceive and specifically obfuscate the inter-service communication topology in a microservice architecture, and they are not designed for non-intrusive, business-harmless obfuscation in a service mesh environment. Therefore, they cannot effectively defend against the topology reconnaissance attacks that this paper focuses on. Summary of the Invention

[0009] This invention provides a cloud-native topology adaptive obfuscation method and system, which solves the problem in the prior art that attackers can obtain the real call topology between services by analyzing traffic metadata, thereby identifying critical paths and core services, and finally launching targeted attacks. It achieves completely harmless fake traffic and effectively hides core services.

[0010] In a first aspect, the present invention provides a topology adaptive obfuscation method for cloud-native applications, the method comprising: Traffic metadata is acquired in real time at fixed time intervals, and the traffic metadata is cleaned to obtain a service flow graph; Based on user needs, the weights of each feature of the original traffic in each node of the service flow graph are determined to obtain an initial weighted undirected graph; Calculate the composite weights between adjacent nodes in the initial weighted undirected graph to obtain the weighted undirected graph, and perform path calculation on the weighted undirected graph based on the DAG algorithm to obtain the critical path; A critical path obfuscation strategy is generated using obfuscation proxies and filters. The critical path is then obfuscated according to the obfuscation strategy to obtain an obfuscated weighted undirected graph.

[0011] In conjunction with the first aspect, in one possible implementation, the step of acquiring traffic metadata in real time at fixed time intervals and cleaning the traffic metadata to obtain a service flow graph includes: By calling the Kiali network interface, service-level topology data is obtained, and a JSON-formatted topology diagram describing the logical dependencies between services is generated. The JSON-formatted topology graph is parsed and mapped into a strongly typed data structure in memory to obtain the first structure data; wherein, the first structure data includes: key traffic feature data such as the number of service dependencies, latency, and error rate; Filter the deployed obfuscated proxies and traffic data related to the obfuscated proxies in the first structure data to obtain a service flow graph.

[0012] In conjunction with the first aspect, in one possible implementation, determining the weights of each feature of the original traffic in each node of the service flow graph based on user needs to obtain an initial weighted undirected graph includes: Determine the application type corresponding to the user's needs, and obtain weight configuration parameters based on the application type; wherein, the weight configuration parameters include: service dependency quantity weight factor, requests per second weight factor, and error rate weight factor; The weight configuration parameters are assigned to each edge of the service flow graph to obtain an initial weighted undirected graph.

[0013] In conjunction with the first aspect, in one possible implementation, calculating the composite weights between adjacent nodes in the initial weighted undirected graph to obtain the weighted undirected graph includes: Traverse each edge of the initial weighted undirected graph; Extract the raw traffic corresponding to the current edge and obtain the weight configuration parameters corresponding to the current edge; Calculate the composite weight of the current edge based on the weight configuration parameters, and add the composite weight to the initial weighted undirected graph; Continue until the traversal is complete, resulting in a weighted undirected graph.

[0014] In conjunction with the first aspect, in one possible implementation, the generation of a critical path obfuscation strategy using obfuscation proxies and filters includes: Traverse each edge on the critical path; Determine the original traffic corresponding to the source node of the current edge, and generate the obfuscated traffic corresponding to the current edge based on the original traffic; Assign the obfuscation proxy to the target node of the current edge, and add a unique obfuscation identifier to the obfuscation proxy to obtain a uniquely identified obfuscation proxy; Configure the filter on the source node corresponding to the current edge, and generate the obfuscation policy corresponding to the current edge based on the unique identifier of the obfuscation proxy and the obfuscated traffic; The critical path obfuscation strategy is obtained after the traversal is completed.

[0015] In conjunction with the first aspect, in one possible implementation, determining the original traffic corresponding to the source node of the current edge, and generating the obfuscated traffic corresponding to the current edge based on the original traffic, includes: Obtain the characteristics of the raw traffic of the current edge, including the number of service dependencies, latency, and error rate; Based on the characteristics of the original traffic and a preset obfuscation strength factor, obfuscated traffic is generated, wherein the obfuscation strength factor is used to adjust the values ​​of service dependency quantity, latency, or error rate; Add a unique obfuscation identifier to the obfuscated traffic to obtain the obfuscated traffic.

[0016] In conjunction with the first aspect, in one possible implementation, obfuscating the critical path according to the critical path obfuscation strategy to obtain an obfuscated weighted undirected graph includes: The filter is configured in the critical path. The filter is used to identify obfuscated traffic in the obfuscation strategy of the critical path based on a unique obfuscation identifier, and to prevent the obfuscated traffic from entering the real business logic by returning the corresponding response. The obfuscated proxy is set on the critical path to generate and send the obfuscated traffic, thereby creating a virtual service call topology and obtaining an obfuscated weighted undirected graph.

[0017] In conjunction with the first aspect, one possible implementation further includes: adaptively updating the critical path obfuscation strategy, specifically including: Traffic metadata is reacquired at fixed time intervals and cleaned to obtain an updated service flow graph; The weights are determined based on user needs, the composite weights are calculated, and the critical path is recalculated to obtain the updated critical path. If the changes in structure or traffic characteristics between the updated critical path and the original critical path exceed a preset threshold, a new obfuscation strategy will be generated. When updating the obfuscation policy according to the new obfuscation policy, prioritize reusing the already deployed obfuscation agent instances and adjust the reserved capacity according to the number of critical path nodes.

[0018] In conjunction with the first aspect, in one possible implementation, the path calculation of the weighted undirected graph based on the DAG (Directed Acyclic Graph) algorithm to obtain the critical path includes: Topological sorting of a weighted undirected graph is performed based on Kahn's algorithm to determine the node processing order. The weight of the longest path from the root node to each node in the weighted undirected graph is calculated using dynamic programming to obtain the ending node. The critical path is determined by backtracking the predecessor node array.

[0019] Secondly, this invention provides a cloud-native topology adaptive obfuscation system, the system comprising: A data acquisition unit is used to acquire traffic metadata in real time at fixed time intervals and clean the traffic metadata to obtain a service flow graph. An undirected graph generator is used to determine the weights of each feature of the original traffic in each node of the service flow graph based on user requirements, and to obtain an initial weighted undirected graph. A critical path analyzer is used to calculate the composite weights between adjacent nodes in the initial weighted undirected graph to obtain a weighted undirected graph, and to perform path calculation on the weighted undirected graph based on the DAG algorithm to obtain the critical path; An obfuscation strategy generator is used to generate a critical path obfuscation strategy using an obfuscation proxy and a filter, and to obfuscate the critical path according to the obfuscation strategy to obtain an obfuscated weighted undirected graph.

[0020] One or more technical solutions provided in this invention have at least the following technical effects or advantages: This invention acquires and cleans traffic metadata in real time at fixed time intervals to obtain a service flow graph, achieving a sliding window-like perception of dynamically changing loads and topologies of cloud-native applications. This provides a precise data foundation for subsequent policy generation, demonstrating the system's dynamic adaptability. Based on this, the weights of each node's characteristics are determined according to user needs to generate an initial weighted undirected graph. Composite weights are then calculated, and the critical path is finally calculated using a Directed Acyclic Graph (DAG) algorithm. This process enables the system to accurately locate core services and paths, providing a prerequisite for subsequent highly targeted obfuscation, thereby significantly enhancing security and greatly increasing the cost and difficulty for attackers to conduct reconnaissance. Finally, obfuscation proxies and filters are used to generate and execute critical path obfuscation policies, resulting in an obfuscated weighted undirected graph. This step is implemented non-intrusively through a Sidecar proxy, requiring no modification to application code for deployment. Simultaneously, a filtering mechanism ensures that fake traffic is only visible at the network layer and is processed before reaching the application, ensuring minimal performance impact. Furthermore, this architecture supports real-time hot updates of obfuscation policies through the control plane, without requiring service restarts, fully demonstrating powerful policy hot update capabilities and ensuring continuous, uninterrupted service operation and timely protection. Attached Figure Description

[0021] Figure 1 A flowchart of a cloud-native topology adaptive obfuscation method provided in this embodiment of the invention; Figure 2 This is a schematic diagram of a cloud-native topology adaptive obfuscation system provided in an embodiment of the present invention. Detailed Implementation

[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0023] Firstly, this invention provides a topology adaptive obfuscation method for cloud-native applications, see [link to relevant documentation]. Figure 1 The method includes the following steps S101 to S104.

[0024] S101: Obtain traffic metadata in real time at fixed time intervals, clean the traffic metadata, and obtain a service flow diagram; Specifically, in step S101, traffic metadata is acquired in real time at fixed time intervals, and the traffic metadata is cleaned to obtain a service flow diagram, including the following steps S1011 to S1013.

[0025] S1011, by calling the Kiali network interface, obtains service-level topology data and generates a JSON-formatted topology diagram describing the logical dependencies between services; S1012, parse the JSON format topology graph and map it into a strongly typed data structure in memory to obtain the first structure data; wherein, the first structure data includes: key traffic feature data such as the number of service dependencies, latency and error rate; S1013, filter the deployed obfuscated proxies and traffic data related to obfuscated proxies in the first structure data to obtain the service flow graph.

[0026] For example, topology data at the service level is obtained from the Kiali network interface: By calling the Kiali interface, a topology snapshot that accurately describes the logical dependencies between services is obtained. Service granularity is chosen because services are stable network endpoints with long lifecycles and are independent of the dynamic scaling of underlying Pods, making them more suitable as targets for logical topology obfuscation. The obtained JSON file is then transformed into a service flow graph: After obtaining the raw JSON data, it is parsed and mapped into a strongly typed, easily manipulated data structure in memory. This process is not just simple deserialization, but also a data cleaning and structuring process, preserving information such as the number of service dependencies. ,Delay and error rate Key traffic characteristic data.

[0027] During the iterative obfuscation process, the deployed obfuscation proxy services will also generate traffic. When conducting a new round of topology analysis, these services and the obfuscated traffic they generate must be excluded; otherwise, they will interfere with the determination of the true business topology.

[0028] S102, Based on user needs, determine the weights of each feature of the original traffic in each node of the service flow graph to obtain the initial weighted undirected graph; Specifically, in step S102, the weights of each feature of the original traffic in each node of the service flow graph are determined based on user needs to obtain an initial weighted undirected graph, including the following steps S1021 to S1022.

[0029] S1011, determine the application type corresponding to the user's needs, and obtain the weight configuration parameters according to the application type; among which, the weight configuration parameters include: service dependency quantity weight factor, requests per second weight factor, and error rate weight factor. S1012 assigns weight configuration parameters to each edge of the service flow graph to obtain the initial weighted undirected graph.

[0030] For example, the weight configuration parameters are not fixed values, but are preset or dynamically adjusted according to the characteristics of different application types or business scenarios. For instance, for financial applications that focus on transaction throughput, higher weights can be configured. w_rps (For example, 0.6) to highlight the importance of high-concurrency links. For core services requiring high stability (such as authentication services), higher values ​​can be configured. w_error (For example, 0.5) to emphasize the impact of error rate on risk. For newly deployed modules, a higher value can be configured. w_service Monitor the invocation status of the new interface. Assign weight configuration parameters to each edge of the service flow graph according to the weight configuration parameters to obtain an initial weighted undirected graph.

[0031] S103, calculate the composite weight between adjacent nodes in the initial weighted undirected graph to obtain the weighted undirected graph, and perform path calculation on the weighted undirected graph based on the DAG algorithm to obtain the critical path; Specifically, in step S103, the composite weights between adjacent nodes in the initial weighted undirected graph are calculated to obtain the weighted undirected graph, including: Traverse every edge of the initial weighted undirected graph; (1) Extract the original traffic corresponding to the current edge and obtain the weight configuration parameters corresponding to the current edge; (2) Calculate the composite weight of the current edge according to the weight configuration parameters, and add the composite weight to the initial weighted undirected graph; Continue until the traversal is complete, resulting in a weighted undirected graph.

[0032] Specifically, in step S103, path calculation is performed on the weighted undirected graph based on the DAG algorithm to obtain the critical path, including: (1) Perform topological sorting on the weighted undirected graph based on Kahn's algorithm to determine the node processing order; (2) Use dynamic programming to calculate the weight of the longest path from the root node to each node in the weighted undirected graph, and obtain the ending node; (3) Determine the critical path by backtracking the predecessor node array.

[0033] For example, the formula for calculating the composite weight is expressed as follows: ; in, This indicates the number of service dependencies in the original traffic; Indicates the delay in the original traffic; This represents the error rate in the raw traffic; Indicates the weight of the number of service dependencies; Indicates the delay weight; This represents the error rate weight.

[0034] The weighted undirected graph is transformed into a flow adjacency matrix, and Kahn's algorithm is used to perform topological sorting on the flow adjacency matrix. Kahn's algorithm maintains a queue of nodes with an in-degree of 0, processes nodes cyclically and updates the in-degree of their neighbors until all nodes are processed or a cycle is detected.

[0035] Initialize the distance array dist: dist[i] stores the sum of the weights of the longest path from the root node to node i.

[0036] All nodes' dist values ​​are initialized to negative infinity, with the root node (usually the entry point service, or any node with an in-degree of 0) having its dist value initialized to 0.

[0037] Initialize the predecessor node array prev: prev[i] stores the node preceding i in the longest path from the root node to node i, used for path backtracking.

[0038] Traverse node u in the order of topological sort order: For each node u, if dist[u] is valid (i.e. reachable): Traverse all outgoing edges u->v of u (v is computeEdge.to in adj[u].

[0039] Get the weight e.weight of edge u->v. If dist[v] is less than dist[u] plus the weight e.weight of edge (u,v): update dist[v] to the new value: dist[v]=dist[u]+e.weight. Record prev[v]=u, which means that the current optimal path to v is from u, and get the final node of the critical path.

[0040] After calculating the dist value for all nodes, find the largest value, maxSum, and its corresponding index endNode is the end point of the critical path. Starting from endNode, backtrack forward using the prev array (current = prev[current]) until returning to the root node (whose prev is -1). This backtracking process reconstructs the entire longest path, i.e., the critical path.

[0041] S104. Generate a critical path obfuscation strategy using obfuscation proxies and filters. Obfuscate the critical path according to the critical path obfuscation strategy to obtain an obfuscated weighted undirected graph.

[0042] Specifically, in step S104, a critical path obfuscation strategy is generated using obfuscation proxies and filters, including: Traverse each edge on the critical path; (1) Determine the original traffic corresponding to the source node of the current edge, and generate the obfuscated traffic corresponding to the current edge based on the original traffic; Here, the original traffic corresponding to the source node of the current edge is determined, and the obfuscated traffic corresponding to the current edge is generated based on the original traffic, including: (1.1) Obtain the characteristics of the raw traffic of the current edge, including the number of service dependencies, latency, and error rate. (1.2) Generate obfuscated traffic based on the characteristics of the original traffic and the preset obfuscation strength factor, wherein the obfuscation strength factor is used to adjust the value of the number of service dependencies, latency or error rate; (1.3) Add a unique obfuscation identifier to the obfuscated traffic to obtain the obfuscated traffic.

[0043] (2) Assign the obfuscation proxy to the target node of the current edge, and add the unique obfuscation identifier to the obfuscation proxy to obtain the unique identifier obfuscation proxy; (3) Configure the filter on the source node corresponding to the current edge, and generate the obfuscation policy corresponding to the current edge based on the unique identifier of the obfuscated proxy and obfuscated traffic; The critical path obfuscation strategy is obtained after the traversal is completed.

[0044] Specifically, in step S104, the critical path is obfuscated according to the critical path obfuscation strategy to obtain an obfuscated weighted undirected graph, including: (1) Configure the filter in the critical path. The filter is used to identify obfuscated traffic in the obfuscation strategy of the critical path based on the unique obfuscation identifier, and prevent obfuscated traffic from entering the real business logic by returning the corresponding response. (2) Set the obfuscated proxy on the critical path to generate and send obfuscated traffic to create a virtual service call topology and obtain an obfuscated weighted undirected graph.

[0045] For example, the present invention does not change the original business traffic path, but uses the service mesh filtering mechanism to identify and filter obfuscated traffic generated by obfuscated proxies, preventing it from interfering with the real business logic.

[0046] Obfuscated traffic generation rules: Obfuscated traffic generation is dynamically adjusted based on the identified critical path and its actual traffic characteristics (such as RPS, error rate, response latency). Specific rules are as follows: Obfuscated Traffic Characteristics: For each obfuscated link on the obfuscated path, the obfuscation proxy (OA) generates forged requests with similar statistical characteristics but harmless to the business based on the actual traffic characteristics of the links corresponding to that link on the critical path, combined with a preset obfuscation strength factor (configurable, such as increasing RPS by 1.5 times, increasing latency by 10%, setting the error rate to a specific value, or randomly fluctuating within a certain percentage range of the actual value).

[0047] Unique Obfuscated Identifier: Each forged request includes a system-generated, random, and unique obfuscated identifier in the HTTP header (e.g., X-MeshGuard-Obfuscated).<random_token> This identifier is key to distinguishing genuine business traffic from obfuscated traffic.

[0048] Unlike traditional traffic obfuscation, this invention does not blindly generate traffic. Instead, it intelligently and purposefully injects obfuscated traffic based on real-time service topology analysis and critical path identification, simulating real communication patterns to achieve precise topology obfuscation. This invention is implemented through the Sidecar proxy (Envoy) mechanism of service meshes (such as Istio), requiring no modification to application code, being non-intrusive to existing systems, and naturally adapting to the dynamic characteristics of cloud-native environments. EnvoyFilter achieves precise filtering and harmless processing of obfuscated traffic at the Sidecar level, ensuring that false traffic does not enter the real application logic layer, avoiding negative impacts on business performance and data—a feature not found in other general traffic obfuscation solutions. Filtering rule generation: Based on the EnvoyFilter configuration code, we generate filtering rules for each service node on the critical path. (Especially those nodes that are downstream targets) generate an EnvoyFilter rule.

[0049] The core logic of this rule is as follows: It is used in services On inbound traffic, the obfuscated proxy checks the headers of every incoming HTTP request using a Lua script (or other filtering mechanisms supported by Envoy). If the request header contains the aforementioned randomized obfuscation flag, the Envoy proxy immediately aborts the request and returns an HTTP 200 OK response. This mechanism allows the obfuscated proxy to send requests to the real service address, but at the data plane level, these requests marked as "obfuscated" are harmlessly processed by the Sidecar proxy before reaching the application container. This allows network-level traffic probing tools (such as Wireshark and eBPF monitoring) to observe the communication between the obfuscated proxy and the real service, thus achieving the purpose of deception, while ensuring that these forged requests do not have any actual impact on the business logic, performance metrics, or logs of the real service.

[0050] The obfuscation strategy determines the number of operational automation (OA) agents to be deployed, depending on the length and complexity of the critical path. For example, for a critical path with N nodes, N-1 obfuscation agents can be deployed, each simulating one or more "hops" on the path.

[0051] For each obfuscation agent on the path, the obfuscation agent is... (For example, simulating from) arrive (Regarding the hop), the algorithm generates a detailed list of downstream node configurations. This list includes obfuscated proxies. All targets that need to be simulated (typically subsequent service nodes on the critical path).

[0052] Injected traffic characteristics: The configuration of each virtual link not only includes the target service address, but also assigns weighted obfuscated traffic characteristics based on the application type and the performance metrics (RPS, latency, error rate) of the original path. For example, an obfuscated proxy can be configured to send 20 requests per second to the target service and simulate a 5% error rate; these values ​​are proportionally adjusted based on real traffic characteristics.

[0053] The method provided by this invention also includes: adaptively updating the critical path obfuscation strategy.

[0054] Specific implementation methods include: (1) Reacquire traffic metadata at fixed time intervals and clean it to obtain an updated service flow graph; (2) Determine the weights based on user needs, calculate the composite weights, and recalculate the critical path to obtain the updated critical path; (3) If the changes in structure or traffic characteristics between the updated critical path and the original critical path exceed a preset threshold, a new obfuscation strategy is generated. (4) When updating the obfuscation strategy according to the new obfuscation strategy, prioritize the reuse of deployed obfuscation agent instances and adjust the reserved capacity according to the number of critical path nodes.

[0055] For example, to adapt to the dynamically changing load and topology of cloud-native applications, this invention designs an adaptive policy update mechanism: Topology acquisition at fixed time intervals: The system reacquires the latest inter-service communication topology from the Kiari network interface at preset time intervals.

[0056] Recalculate the critical path and determine if the strategy needs to be updated: Judgment logic: The system will recalculate the new critical path. If the structure of the old and new critical paths (such as the number of nodes, edges, or connections) changes, or if the changes in the corresponding traffic characteristics (RPS, error rate) on the old and new critical paths exceed a preset threshold (e.g., 15%), then it is determined that the obfuscation strategy needs to be updated.

[0057] Objective: To ensure that the obfuscation strategy is always based on the latest system state, and to avoid obfuscation failure or over-obfuscation.

[0058] Reuse and reservation of obfuscated proxies: Reuse mechanism: If an obfuscation policy is regenerated, the system will prioritize reusing existing obfuscation proxy instances. This reduces resource overhead and latency caused by frequent creation and destruction of Pods.

[0059] Reserved Capacity: To improve response speed, the obfuscated proxy also reserves approximately 10% of additional instance capacity. If the number of new critical path nodes exceeds the original number, these reserved instances can be quickly put into use, thereby reducing the time required to create the obfuscated proxy. If the number of new critical path nodes is less than the original number, simply set the downstream node configuration of the excess obfuscated proxy to empty; there is no need to destroy them, allowing for future reuse.

[0060] Secondly, this invention provides a cloud-native topology adaptive obfuscation system, see [link to relevant documentation]. Figure 2 The system includes: The data acquisition unit is used to acquire traffic metadata in real time at fixed time intervals and clean the traffic metadata to obtain a service flow graph. An undirected graph generator is used to determine the weights of each feature of the original traffic in each node of the service flow graph based on user requirements, and to obtain an initial weighted undirected graph. The critical path analyzer is used to calculate the composite weights between adjacent nodes in the initial weighted undirected graph to obtain the weighted undirected graph, and to calculate the path in the weighted undirected graph based on the DAG algorithm to obtain the critical path; The obfuscation strategy generator is used to generate critical path obfuscation strategies using obfuscation proxies and filters, and obfuscates the critical paths according to the critical path obfuscation strategies to obtain an obfuscated weighted undirected graph.

[0061] For example, in a cloud-native microservice system of an e-commerce platform, the security team applied this topology adaptive obfuscation system to improve the architecture's stealth: The data acquisition device periodically retrieves inter-service call data from the Kiali interface, filters out non-core nodes such as the log service, and generates a service flow diagram that includes the order service, inventory service, and payment service. The undirected graph generator configures a weight factor of 0.6 for payment nodes based on the characteristics of financial applications (high concurrency sensitivity), and constructs an initial weighted undirected graph that highlights the payment chain; After calculating the composite weights, the critical path analyzer uses the DAG algorithm to identify the highest risk path: "user authentication → payment risk control → third-party payment interface". The obfuscation strategy generator then deployed an Envoy filter at the risk control service entry point, and simultaneously launched an obfuscation proxy to inject fake authentication traffic carrying a unique obfuscation identifier into the risk control service. When attackers conducted network reconnaissance, they observed dozens of call paths containing fake risk control nodes, while the real payment risk control interface was effectively hidden in the chaotic topology, significantly increasing the difficulty of the attack.

[0062] The various embodiments described in this specification are presented in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. All or part of this invention can be used in numerous general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, mobile communication terminals, multiprocessor systems, microprocessor-based systems, programmable electronic devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices, etc.

[0063] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the present invention.

Claims

1. A topology adaptive obfuscation method for cloud-native computing, characterized in that, include: Traffic metadata is acquired in real time at fixed time intervals, and the traffic metadata is cleaned to obtain a service flow graph; Based on user needs, the weights of each feature of the original traffic in each node of the service flow graph are determined to obtain an initial weighted undirected graph; Calculate the composite weights between adjacent nodes in the initial weighted undirected graph to obtain the weighted undirected graph, and perform path calculation on the weighted undirected graph based on the DAG algorithm to obtain the critical path; A critical path obfuscation strategy is generated using obfuscation proxies and filters. The critical path is then obfuscated according to the obfuscation strategy to obtain an obfuscated weighted undirected graph.

2. The cloud-native topology adaptive obfuscation method according to claim 1, characterized in that, The process of acquiring traffic metadata in real time at fixed time intervals and cleaning the traffic metadata to obtain a service flow graph includes: By calling the Kiali network interface, service-level topology data is obtained, and a JSON-formatted topology diagram describing the logical dependencies between services is generated. The JSON-formatted topology graph is parsed and mapped into a strongly typed data structure in memory to obtain the first structure data; wherein, the first structure data includes: key traffic feature data such as the number of service dependencies, latency, and error rate; Filter the deployed obfuscated proxies and traffic data related to the obfuscated proxies in the first structure data to obtain a service flow graph.

3. The cloud-native topology adaptive obfuscation method according to claim 1, characterized in that, The process of determining the weights of each feature of the original traffic in each node of the service flow graph based on user needs to obtain an initial weighted undirected graph includes: Determine the application type corresponding to the user's needs, and obtain weight configuration parameters based on the application type; wherein, the weight configuration parameters include: service dependency quantity weight factor, requests per second weight factor, and error rate weight factor; The weight configuration parameters are assigned to each edge of the service flow graph to obtain an initial weighted undirected graph.

4. The cloud-native topology adaptive obfuscation method according to claim 1, characterized in that, The calculation of the composite weights between adjacent nodes in the initial weighted undirected graph to obtain the weighted undirected graph includes: Traverse each edge of the initial weighted undirected graph; Extract the raw traffic corresponding to the current edge and obtain the weight configuration parameters corresponding to the current edge; Calculate the composite weight of the current edge based on the weight configuration parameters, and add the composite weight to the initial weighted undirected graph; Continue until the traversal is complete, resulting in a weighted undirected graph.

5. The cloud-native topology adaptive obfuscation method according to claim 1, characterized in that, The method of generating a critical path obfuscation strategy using obfuscation proxies and filters includes: Traverse each edge on the critical path; Determine the original traffic corresponding to the source node of the current edge, and generate the obfuscated traffic corresponding to the current edge based on the original traffic; Assign the obfuscation proxy to the target node of the current edge, and add a unique obfuscation identifier to the obfuscation proxy to obtain a uniquely identified obfuscation proxy; Configure the filter on the source node corresponding to the current edge, and generate the obfuscation policy corresponding to the current edge based on the unique identifier of the obfuscation proxy and the obfuscated traffic; The critical path obfuscation strategy is obtained after the traversal is completed.

6. The cloud-native topology adaptive obfuscation method according to claim 5, characterized in that, The process of determining the original traffic corresponding to the source node of the current edge and generating the obfuscated traffic corresponding to the current edge based on the original traffic includes: Obtain the characteristics of the raw traffic of the current edge, including the number of service dependencies, latency, and error rate; Based on the characteristics of the original traffic and a preset obfuscation strength factor, obfuscated traffic is generated, wherein the obfuscation strength factor is used to adjust the values ​​of service dependency quantity, latency, or error rate; Add a unique obfuscation identifier to the obfuscated traffic to obtain the obfuscated traffic.

7. The cloud-native topology adaptive obfuscation method according to claim 1, characterized in that, The step of obfuscating the critical path according to the critical path obfuscation strategy to obtain an obfuscated weighted undirected graph includes: The filter is configured in the critical path. The filter is used to identify obfuscated traffic in the obfuscation strategy of the critical path based on a unique obfuscation identifier, and to prevent the obfuscated traffic from entering the real business logic by returning the corresponding response. The obfuscated proxy is set on the critical path to generate and send the obfuscated traffic, thereby creating a virtual service call topology and obtaining an obfuscated weighted undirected graph.

8. The cloud-native topology adaptive obfuscation method according to claim 1, characterized in that, Also includes: Adaptively updating the critical path obfuscation strategy specifically includes: Traffic metadata is reacquired at fixed time intervals and cleaned to obtain an updated service flow graph; The weights are determined based on user needs, the composite weights are calculated, and the critical path is recalculated to obtain the updated critical path. If the changes in structure or traffic characteristics between the updated critical path and the original critical path exceed a preset threshold, a new obfuscation strategy will be generated. When updating the obfuscation policy according to the new obfuscation policy, prioritize reusing the already deployed obfuscation agent instances and adjust the reserved capacity according to the number of critical path nodes.

9. The cloud-native topology adaptive obfuscation method according to claim 1, characterized in that, The path calculation based on the DAG algorithm to obtain the critical path in the weighted undirected graph includes: Topological sorting of a weighted undirected graph is performed based on Kahn's algorithm to determine the node processing order. The weight of the longest path from the root node to each node in the weighted undirected graph is calculated using dynamic programming to obtain the ending node. The critical path is determined by backtracking the predecessor node array.

10. A cloud-native topology adaptive obfuscation system, characterized in that, include: A data acquisition unit is used to acquire traffic metadata in real time at fixed time intervals and clean the traffic metadata to obtain a service flow graph. An undirected graph generator is used to determine the weights of each feature of the original traffic in each node of the service flow graph based on user requirements, and to obtain an initial weighted undirected graph. A critical path analyzer is used to calculate the composite weights between adjacent nodes in the initial weighted undirected graph to obtain a weighted undirected graph, and to perform path calculation on the weighted undirected graph based on the DAG algorithm to obtain the critical path; An obfuscation strategy generator is used to generate a critical path obfuscation strategy using an obfuscation proxy and a filter, and to obfuscate the critical path according to the obfuscation strategy to obtain an obfuscated weighted undirected graph.

Images