Method for micro-service dynamic access control policy under zero trust architecture, and apparatus

Abstract

The present invention belongs to the fields of network security, distributed systems, zero trust, and micro-services, and disclosed are a method for a micro-service dynamic access control policy under a zero trust architecture, and an apparatus. The method specifically comprises: obtaining context information in a micro-service runtime context event by means of an event tracker of a node; a context manager collecting and aggregating the context information and reporting same to a micro-service control plane global manager; the global manager determining whether a new micro-service instance is present according to a global context mapping table value, and if yes, updating a global and local tag mapping table; when a message is received by a node, a message validator obtaining a tag value carried by the message, and micro-service context information corresponding to the message being obtained by means of the local tag mapping table; after a local policy table and a global policy table are queried, running a decision algorithm, and executing a corresponding access control policy. The present invention uses context to identify a communication endpoint, and has the advantages of being dynamic, precise, and extensible.

Description

A method and device for dynamic access control strategy of microservices under zero trust architecture Technical Field

[0001] The present invention belongs to the fields of network security, distributed systems, zero trust, and microservices, and specifically provides a method and device for dynamic access control strategy of microservices under a zero trust architecture. Background Art

[0002] Microservices is a deployment model that has been widely adopted by enterprise applications in recent years. By dividing a single application into a set of services with independent functions, and calling each other through the network, it provides agile, reliable, and reusable functions, thereby providing value to enterprise users.

[0003] Traditional microservice security strategies typically implement unified access policy control by deploying firewalls and gateways at the microservice data center entrance. This approach primarily establishes a security perimeter at the network boundary to control access to north-south traffic. However, as workloads in enterprise data centers expand, internal services interact with each other, and east-west traffic continues to grow, unprotected internal services become entry points for unauthorized access, spreading security risks internally.

[0004] For example, the Chinese patent application publication number CN114519196A discloses a dynamic access control policy evaluation method for microservices, which includes two parts: streamlining and optimizing the policy set based on the attribute similarity calculation method and dynamic access control policy evaluation based on the matching tree structure. It mainly focuses on the three stages of policy streamlining and optimization, matching tree construction, and dynamic policy evaluation based on the matching tree. By using the attribute-based similarity calculation method, access control conflicts and redundant policies are fine-grained and eliminated, reducing the interference of irrelevant policies. By constructing the matching tree structure, the policy retrieval and matching efficiency is improved. At the same time, during the dynamic change of the microservice policy library, only the policy update in the matching tree is maintained locally, and the rest of the policy continues to be evaluated, ensuring the secure implementation of microservice access control and protecting the data security of the microservice system.

[0005] For example, the Chinese patent application publication number CN113051602A discloses a database fine-grained access control method based on a zero-trust architecture. The method is characterized in that the user sends a data access request and a digital certificate to the proxy gateway in the zero-trust architecture as a policy execution point. The proxy gateway performs identity authentication and decides whether to continue processing the data access request. The proxy gateway then forwards the access request to the policy engine through the policy management process of the zero-trust architecture. The policy engine obtains real-time dynamic information for trust calculation. The policy engine then combines the trust calculation results and static information to generate an instantiated access attribute tuple, matches it with the access control policy, and determines whether the access is allowed or denied. Finally, the policy manager receives the policy engine's decision information, authorizes the user based on the decision information, and the user's access request is processed in the database. This invention combines zero-trust architecture technology, trust calculation technology, and access control technology to protect the data integrity and confidentiality of distributed databases.

[0006] The above patents all have the following problems: 1) It requires a large amount of computing resources to analyze the messages; 2) Firewalls and gateways are deployed at the data center entrance of the microservice to uniformly control access policies. Summary of the Invention

[0007] In response to the shortcomings of the existing technology, the present invention proposes a method and device for dynamic access control policies for microservices under a zero-trust architecture. Through software-defined boundaries, the traditional network device-based boundaries are transformed into software-defined logic. The microservice runtime context events are obtained through the node's event tracker. The context manager collects and aggregates the context information reported by the event tracker, and stores and updates the collected and aggregated context information to the local context mapping table. The context manager reports the aggregated context information to the global manager of the microservice control plane, and the global manager updates the global context mapping table. The global manager determines whether it is a newly added microservice instance based on the value of the global context mapping table. If it is a newly added microservice instance, the global tag mapping table and the local tag mapping table are updated. When the node receives a message, the message validator obtains the tag carried by the message, obtains the microservice context information corresponding to the message through the local tag mapping table, queries the local policy table and the global policy table, and executes the corresponding permission or rejection access control policy.

[0008] To achieve the above object, the present invention provides the following technical solutions:

[0009] A method for dynamic access control policy for microservices under a zero-trust architecture, comprising:

[0010] Step S1: Obtain context information in the microservice runtime context event through the node's event tracker;

[0011] Step S2: The context manager collects and aggregates the context information reported by the event tracker, and stores and updates the collected and aggregated context information to the local context mapping table;

[0012] Step S3: The context manager reports the aggregated context information to the microservice control plane global manager, which then updates the global context mapping table.

[0013] Step S4: The global manager determines whether it is a newly added microservice instance based on the value of the global context mapping table. If it is a newly added microservice instance, the global tag mapping table and the local tag mapping table are updated;

[0014] Step S5: When the node receives the message, the message validator obtains the tag value carried by the message and obtains the microservice context information corresponding to the message through the local tag mapping table;

[0015] Step S6: query the local policy table and the global policy table, run the decision algorithm, and execute the corresponding permission or rejection access control policy.

[0016] Specifically, the event tracker in step S1 includes: a process event tracker, a socket event tracker, and an extended event tracker. The process event tracker collects context information such as the process ID, namespace, and running application name of the newly created process during runtime. The socket event tracker tracks socket creation, listening, and address binding events. The extended event tracker implements dynamic and scalable microservice context collection through a hot-loadable event tracker.

[0017] Specifically, the specific steps implemented by the event tracker in step S1 include:

[0018] Step S101: compile the extended Berkeley packet filter using just-in-time compilation technology;

[0019] Step S102: hot-loading the compiled Berkeley packet filter bytecode to different kernel Hook points;

[0020] Step S103: Complete the collection of kernel events and report them to the user space.

[0021] Specifically, the content of the context manager in step S2 specifically includes:

[0022] Step S201: providing a query channel for microservice context information;

[0023] Step S202: Obtain the globally unique tag value of the microservice instance from the control plane global manager and store it in the local tag value mapping table in the kernel space for the message marker on the node to query and mark the sent messages.

[0024] Specifically, the specific steps of the message marker in step S202 include:

[0025] Step S2021: The microservice instance sends a message, and the message marker intercepts it to obtain message information;

[0026] Step S2022: Based on the <namespace, source address, source port> information of the message, query the socket meta-information table and the local tag mapping table to obtain the microservice to which the message belongs and the corresponding tag value;

[0027] Step S2023: Record the tag value into the IPOption field or the Vxlan header field according to the network topology where the microservice is deployed, completing the tag value marking;

[0028] Step S2024: Send the message marked with the tag value to the cluster microservice through the node physical network interface.

[0029] Specifically, the specific steps of the message verifier receiving the message in step S5 are:

[0030] Step S501: The message validator receives the message sent by the sending microservice;

[0031] Step S502: Decode the tag value from the IP Option or Vxlan header, and query the local tag value mapping table to determine whether the entry corresponding to the tag value exists and is valid;

[0032] Step S503: If the tag value is valid, obtain the sender microservice namespace value of the tag value mapping table, query the local context table, obtain the sender microservice context, and continue the decision process. If the tag value is invalid, submit the tag value to the local context manager to trigger the tag mapping table synchronization task.

[0033] Specifically, the specific steps in step S6 are:

[0034] Step S601: According to the <destination interface, destination IP, destination port> of the message, query the local socket meta-information table to obtain the namespace of the receiving end;

[0035] Step S602: query the local context table and the local tag mapping table to obtain the context information of the receiving end and the corresponding tag value;

[0036] Step S603: query the decision cache table. If the decision result does not exist or is expired, query the local decision table, use the iterative strategy table to calculate the decision result and update the decision cache table. The specific formula of strategy π(s) is: π(s)=argmax α∑ s′,r (r+γv(s′)),

[0037] Where α represents the action, s represents the current state, s′ represents the state after the transfer, r represents the reward when s is transferred, γ represents the loss factor, and v(·) represents the state value function;

[0038] Step S604: Run the decision algorithm. According to the result of the decision algorithm, the message verifier releases or discards the message and executes the corresponding permission or rejection access control policy.

[0039] Specifically, the specific implementation method of the access control policy in step S604 includes:

[0040] Step S6041: Obtain the runtime context information of the microservice through the event tracker deployed in the kernel state;

[0041] Step S6042: Based on the tag mapping table and the context mapping table, the context of the communication sender does not need to be carried in the communication data stream;

[0042] Step S6043: The event-based context collection method implements a dynamic execution strategy by setting an expiration event for the context mapping table entry. The specific formula is: L(y,ξ(x,θ))=|ξ(x,θ)-y|<ε,

[0043] Among them, ξ(·) represents the decision function, θ represents a set of learning parameters, x represents the input tag value data, y represents the output tag value data, L(y,ξ(x,θ)) represents the loss function, and ε is a positive number.

[0044] Secondly, the structured risk function is calculated to improve the prediction ability of unknown data. The smaller the structured risk, the more complex the decision function of the model. The structured risk function S(ξ) is:

[0045] Among them, r(θ) represents the number of feature items in the loss function, N represents the number of data, and x i Indicates the i-th input Tag value data, y i represents the i-th output Tag value data, and f(·) represents the mapping function.

[0046] A microservice dynamic access control policy system under a zero-trust architecture, including: a microservice scheduling cluster module, a service node module and an access control module.

[0047] The microservice scheduling cluster module is used to receive context information transmitted by the context manager and determine whether it is a microservice instance;

[0048] The service node module is used to map website content and provide website content stored in the nearest server according to the user's region;

[0049] The access control policy module is used to support dynamic context collection and distribution, and use access control policies to judge, match and filter the obtained Tag values.

[0050] Specifically, the service node module includes a context manager unit, an event tracker unit, a policy agent unit, a message marker unit and a message validator unit.

[0051] The context manager unit is used to monitor and track microservice kernel events and collect context information associated with the microservice;

[0052] The event tracker unit is used to collect events reported by the event tracker and aggregate the context information of the microservice instance through <namespace, process Pid>;

[0053] The policy agent unit is used to obtain access control policies and synchronize them to the local policy table so as to perform fast access policy verification on the node;

[0054] The message marker unit is used to mark all external data messages of the microservice;

[0055] The message validator unit is used to release the data message to the target microservice instance or discard the message.

[0056] Specifically, an electronic device includes a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, it implements the steps of a method for dynamic access control policy of microservices under a zero-trust architecture.

[0057] Specifically, a computer-readable storage medium is characterized in that computer instructions are stored thereon, and when the computer instructions are executed, the steps of a method for dynamic access control policy of microservices under a zero-trust architecture are executed.

[0058] Compared with the prior art, the present invention has the following beneficial effects:

[0059] 1. The present invention proposes a microservice dynamic access control policy system under a zero-trust architecture, and optimizes and improves the architecture, operation steps and processes. The system has the advantages of simple process, low investment and operation costs, and low production work costs.

[0060] 2. The present invention proposes a method for dynamic access control policies for microservices under a zero-trust architecture. By associating microservice instances with a set of context information and using the context to identify communication endpoints, the method has the advantages of being dynamic, precise, and scalable. When the parameters of the microservice instance change during runtime, the context parameters collected by the event tracker are updated at the same time. In this way, the access control policy based on the microservice context can take effect immediately, enhancing security.

[0061] 3. This paper proposes a method for implementing dynamic access control policies for microservices within a zero-trust architecture. By deploying an event tracker in kernel state to obtain runtime contextual information about microservices, this method not only ensures security but also allows for the expansion and deployment of different event trackers as needed to collect more contextual information and precisely define the state of communication endpoints. Based on tag mapping tables and context mapping tables, the sender's context need not be carried in the communication data stream, resulting in low system resource usage, good scalability, and support for all communication protocols.

[0062] 4. This invention proposes a method for dynamic access control policy of microservices under zero trust architecture, an event-based context collection method, and an expiration event of the context mapping table entry, which has the advantages of meeting real-time analysis and dynamic execution of policies. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] FIG1 is a flow chart of a method for dynamic access control strategy of microservices under a zero-trust architecture according to the present invention;

[0064] FIG2 is a flowchart of microservice context information collection and aggregation of a method for dynamic access control strategy of microservices under a zero-trust architecture of the present invention;

[0065] FIG3 is a flow chart of a method for sending microservice messages using a dynamic access control strategy for microservices under a zero-trust architecture according to the present invention;

[0066] FIG4 is a flow chart of a microservice message receiving method of a microservice dynamic access control strategy under a zero-trust architecture according to the present invention;

[0067] FIG5 is a diagram illustrating a system architecture of dynamic access control policies for microservices under a zero-trust architecture according to the present invention;

[0068] Figure 6 is an electronic device diagram of a method for dynamic access control strategy of microservices under a zero-trust architecture of the present invention. DETAILED DESCRIPTION

[0069] In order to make the technical means, creative features, objectives and effects achieved by the present invention easy to understand, it should be noted that in the description of the present invention, the terms "center", "up", "down", "left", "right", "vertical", "horizontal", "inside", "outside" and the like indicate directions or positional relationships based on the directions or positional relationships shown in the accompanying drawings, which are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific direction, be constructed and operated in a specific direction, and therefore cannot be understood as a limitation on the present invention. In addition, the terms "No. 1", "No. 2" and "No. 3" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance. The present invention will be further explained below in conjunction with specific embodiments.

[0070] Example 1

[0071] Referring to Figures 1 to 4 , an embodiment of the present invention provides a method for implementing a dynamic access control policy for microservices under a zero-trust architecture, including:

[0072] Step S1: Obtain context information in the microservice runtime context event through the node's event tracker;

[0073] A node is an edge server that maps website content and provides users with website content stored in the server closest to them based on their location.

[0074] The event tracer is used to monitor and trace kernel events related to microservices and collect contextual information associated with microservices. It can record kernel and application-defined events in log files and use them in real time. Event tracing components are divided into controllers, providers, and consumers. The controller is used to define the size and location of log files, start and stop event tracing sessions, and enable providers. Providers contain applications detected by event tracing. There are four types of providers: MOF providers, WPP providers, manifest-based providers, and TraceLogging providers. Consumers are applications that select one or more event tracing sessions as event sources.

[0075] Step S2: The context manager collects and aggregates the context information reported by the event tracker, and stores and updates the collected and aggregated context information to the local context mapping table;

[0076] Context managers are a powerful mechanism for managing resource acquisition and release, providing a concise and secure way to open, close, and handle exceptions. This makes code readable and maintainable while enhancing program robustness. Context managers are also responsible for reporting local context information to the microservice control center to support cross-node access control.

[0077] Step S3: The context manager reports the aggregated context information to the microservice control plane global manager, which then updates the global context mapping table.

[0078] Step S4: The global manager determines whether it is a newly added microservice instance based on the value of the global context mapping table. If it is a newly added microservice instance, the global tag mapping table and the local tag mapping table are updated;

[0079] Step S5: When the node receives the message, the message validator obtains the tag value carried by the message and obtains the microservice context information corresponding to the message through the local tag mapping table;

[0080] Step S6: query the local policy table and the global policy table, run the decision algorithm, and execute the corresponding permission or rejection access control policy.

[0081] The event trackers in step S1 include: process event tracker, socket event tracker, and extended event tracker. The process event tracker collects context information such as the process ID, namespace, and running application name of the newly created process during runtime. The socket event tracker tracks socket creation, listening, and address binding events. The extended event tracker implements dynamic and scalable microservice context collection through a hot-loadable event tracker.

[0082] The process ID can be associated with the context of a specific application process within a microservice, and the namespace value can be associated with all contexts belonging to the same microservice on the node. At the same time, the event tracker must be run on every microservice deployment node.

[0083] The specific steps implemented by the event tracker in step S1 include:

[0084] Step S101: compile the extended Berkeley packet filter using just-in-time compilation technology;

[0085] The Extended Berkeley Packet Filter (eBPF) consists of two parts: user mode and kernel mode. User mode programs need to interact with the kernel through Berkeley Packet Filter (BPF) system calls to complete tasks such as eBPF program loading, event mounting, and mapping creation and update. In kernel mode, eBPF programs cannot call kernel functions arbitrarily, but need to use BPF auxiliary functions to complete the required tasks.

[0086] Just-in-Time (JIT) technology analyzes the execution process, selectively compiling hotspot code into machine code and caching it. It also incorporates code optimizations during the compilation process to make code execution more efficient. The main steps of JIT are: 1) If the program has only one BPF function, return directly; 2) Filter out all internal function call instructions; 3) For each function call, construct and initialize a subroutine data structure; 4) Call bpf_int_jit_compile for each subroutine; 5) Correct the offset of the jump instruction and save it to insn->imm; 6) Call bpf_int_jit_compile to correct the jump offset again; 7) Call bpf_prog_lock_ro to change the access rights of each function's code segment to RO; 8) Call bpf_prog_kallsyms_add to add the symbol information of each function to kallsyms.

[0087] Step S102: hot-loading the compiled Berkeley packet filter bytecode to different kernel Hook points;

[0088] Step S103: Complete the collection of kernel events and report them to user space

[0089] The content of the context manager in step S2 specifically includes:

[0090] Step S201: providing a query channel for microservice context information;

[0091] Step S202: Obtain the globally unique tag value of the microservice instance from the control plane global manager and store it in the local tag value mapping table in the kernel space for the message marker on the node to query and mark the sent messages.

[0092] The context manager of each node obtains the microservice tag value mapping table from the global manager and stores it in the local tag value mapping table in the kernel space for the message marker to query. The key values ​​of the tag mapping table are: Tag: <namespace, instance Id>.

[0093] The specific steps of the message marker in step S202 include:

[0094] Step S2021: The microservice instance sends a message, and the message marker intercepts it to obtain message information;

[0095] Step S2022: Based on the <namespace, source address, source port> information of the message, query the socket meta-information table and the local tag mapping table to obtain the microservice to which the message belongs and the corresponding tag value;

[0096] Step S2023: Record the tag value into the IPOption field or the Vxlan header field according to the network topology where the microservice is deployed, completing the tag value marking;

[0097] Step S2024: Send the message marked with the tag value to the microservice of the cluster through the node physical network interface.

[0098] The specific steps of the message verifier receiving the message in step S5 are:

[0099] Step S501: The message validator receives the message sent by the sending microservice;

[0100] Step S502: Decode the tag value from the IP Option or Vxlan header, query the local tag value mapping table, and obtain the microservice context information corresponding to the message;

[0101] Step S503: Determine whether the table entry corresponding to the tag value exists and is valid. If the tag value is valid, obtain the sending end microservice namespace value of the tag value mapping table, query the local context table, obtain the sending end microservice context, and continue the decision-making process. If the tag value is invalid, submit the tag value to the local context manager to trigger the tag mapping table synchronization task.

[0102] The specific steps in step S6 are:

[0103] Step S601: According to the <destination interface, destination IP, destination port> of the message, query the local socket meta-information table to obtain the namespace of the receiving end;

[0104] Step S602: query the local context table and the local tag mapping table to obtain the context information of the receiving end and the corresponding tag value;

[0105] Step S603: query the decision cache table. If the decision result does not exist or is expired, query the local decision table, use the iterative strategy table to calculate the decision result and update the decision cache table. The specific formula of strategy π(s) is: π(s)=arg max α ∑ s′,r (r+γv(s′)),

[0106] Where α represents the action, s represents the current state, s′ represents the state after the transfer, r represents the reward when s is transferred, γ represents the loss factor, and v(·) represents the state value function;

[0107] A decision table, also known as a judgment table, is a tabular graphical tool suitable for describing situations involving multiple conditions, combinations of conditions, and multiple decision options. It accurately and concisely describes complex logic, mapping multiple conditions to the actions to be performed when those conditions are met. However, unlike control statements in traditional programming languages, a decision table clearly illustrates the direct connection between multiple independent conditions and multiple actions. A decision table consists of four parts: condition piles, action piles, condition items, and action items.

[0108] Strategy is to decide what action to take based on the current state. Strategy iteration includes strategy evaluation and strategy improvement. Strategy evaluation is used to judge the quality of the strategy, which is reflected by expected value. The specific formula of expected value is: V(s) = max α ∑ s′,r p(s′,r|s,α)[r+γV(s′)],

[0109] Where V(s) represents the expected value and P(·) represents the conditional probability.

[0110] Strategy improvement is to find the best strategy. The specific formula is:

[0111] Assume that π and π′ are a pair of deterministic strategies, then q π (s,π′(s))≥v π (s),

[0112] Among them, q π (·) represents the action value function, v π (·) represents the state-value function of policy π.

[0113] Step S604: Run the decision algorithm. Based on the result of the decision algorithm, the message verifier releases or discards the message and executes the corresponding permission or rejection access control policy. The specific formula is: L(y,ξ(x,θ))=|ξ(x,θ)-y|<ε,

[0114] Among them, ξ(·) represents the decision function, θ represents a set of learning parameters, x represents the input tag value data, y represents the output tag value data, L(y,ξ(x,θ)) represents the loss function, and ε represents a small positive number.

[0115] Secondly, the structured risk function is calculated to improve the predictive ability of unknown data. The smaller the structured risk, the more complex the decision function of the model. The structured risk function is:

[0116] Among them, r(θ) represents the number of feature items in the loss function, N represents the number of data, and x i Indicates the i-th input Tag value data, y irepresents the i-th output Tag value data, and f(·) represents the mapping function.

[0117] The loss function forms the basis of expected risk, empirical risk, and structural risk. It is specific to a single sample and represents the difference between the model's predicted value and the sample's true value. Minimizing empirical risk is about minimizing this function, which is the average minimization of the loss function for all sample points in the training set. A smaller empirical risk indicates a better fit of the model to the training set. Overfitting occurs when the empirical risk function becomes too small. This suggests that the complexity of the model's decision function is a necessary condition for overfitting.

[0118] The specific implementation method of the access control policy in step S604 is:

[0119] Step S6041: Obtain the context information of the microservice runtime through the event tracker deployed in the kernel state to accurately define the state of the communication endpoint;

[0120] Step S6042: Based on the tag mapping table and the context mapping table, the context of the communication sender does not need to be carried in the communication data stream, which has the advantages of low system resource usage and good scalability, and supports all communication protocols;

[0121] Step S6043: The event-based context collection method and setting of expiration events for context mapping table entries have the advantages of meeting the requirements of real-time analysis and dynamic execution strategies.

[0122] Access control policies are the primary strategy for network security prevention and protection, ensuring that network resources are protected from unauthorized use and access. Access control policies include network access control policies, operational authority control policies, directory security control policies, attribute security control policies, network server security control policies, network monitoring, locking control policies, and firewall control policies. Network access control is the first layer of network access security. It controls which users can log in to the server and gain access to network resources, and governs the time and location of user access. Operational authority control provides security measures against potential illegal network operations. Directory security allows user operations at the directory level to apply to all files and subdirectories within the directory. Attribute security control policies allow access attributes to be associated with files, directories, and network devices on the network server. Network server security controls include the ability to set passwords to lock the server console to prevent unauthorized users from modifying the system, deleting important information, or destroying data. Network servers should log user access to network resources. Servers should issue alerts in the form of images, text, or sound for unauthorized network access. A firewall is a technical measure for protecting computer networks, acting as a barrier to prevent hackers from entering the corporate intranet.

[0123] Example 2

[0124] Please refer to FIG5 , another embodiment provided by the present invention: a microservice dynamic access control policy system under a zero-trust architecture, comprising: a microservice scheduling cluster module, a service node module and an access control policy module,

[0125] The microservice scheduling cluster module is mainly a control plane global manager module, which is used to receive context information transmitted by the context manager and determine whether it is a microservice instance;

[0126] The service node module includes user space and kernel space, and is used to map website content and provide website content stored in the nearest server according to the user's region;

[0127] The access control policy module is used to support dynamic context collection, distribution, and decision-making algorithms.

[0128] The service node module includes a context manager unit, an event tracker unit, a policy agent unit, a message marker unit and a message validator unit.

[0129] The context manager unit is used to monitor and track kernel events related to microservices and collect context information associated with microservices;

[0130] The event tracker unit is used to collect events reported by the event tracker and aggregate the context information of the microservice instance through <namespace, process Pid>;

[0131] The policy agent unit is used to obtain access control policies and synchronize them to the local policy table so as to perform fast access policy verification on the node;

[0132] The message marker unit is used to mark all external data messages of the microservice;

[0133] The message validator unit is used to release the data message to the target microservice instance or discard the message.

[0134] Example 3

[0135] Please refer to Figure 6, an electronic device includes a memory and a processor, the memory stores a computer program, and the processor implements a method and steps for implementing a dynamic access control policy for microservices under a zero-trust architecture when executing the computer program.

[0136] A computer-readable storage medium, characterized in that computer instructions are stored thereon, and when the computer instructions are executed, a method step of executing a dynamic access control policy for microservices under a zero-trust architecture is executed.

[0137] It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0138] The present invention is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0139] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0140] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0141] The embodiments of the present invention are described above in conjunction with the accompanying drawings, but the present invention is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present invention, ordinary technicians in this field can also make many forms without departing from the scope of protection of the purpose of the present invention and the claims, which are all protected by the present invention.

Claims

1. A method for dynamic access control strategy of microservices under zero trust architecture, characterized in that: include: Step S1: Obtain context information in the microservice runtime context event through the node's event tracker; Step S2: collecting and aggregating the context information reported by the event tracker through the context manager, and storing and updating the collected and aggregated context information to the local context mapping table; Step S3: The context manager reports the aggregated context information to the microservice control plane global manager, and the global manager updates the global context mapping table; Step S4: The global manager determines whether it is a newly added microservice instance based on the value of the global context mapping table. If it is a newly added microservice instance, the global tag mapping table and the local tag mapping table are updated; Step S5: When the node receives the message, the message verifier obtains the Tag value carried by the message, and obtains the microservice context information corresponding to the message through the local Tag mapping table; Step S6: query the local policy table and the global policy table, run the decision algorithm, and execute the corresponding permission or denial access control policy.

2. A method for dynamic access control strategy of microservices under zero trust architecture as described in claim 1, characterized in that: The event tracker in step S1 includes: a process event tracker, a socket event tracker, and an extended event tracker. The process event tracker collects context information such as the process ID, namespace, and running application name of the newly created process when it is running. The socket event tracker tracks socket creation, monitoring, and address binding events. The extended event tracker implements dynamic and scalable microservice context collection through a hot-loadable event tracker.

3. The method of microservice dynamic access control strategy under zero trust architecture described in claim 2 is characterized in that: The specific steps implemented by the event tracker in step S1 include: Step S101: compile the extended Berkeley packet filter using the just-in-time compilation technology; Step S102: hot-loading the compiled Berkeley packet filter bytecode to different kernel Hook points; Step S103: Complete the collection of kernel events and report them to the user space.

4. A method for dynamic access control strategy of microservices under zero trust architecture as described in claim 3, characterized in that: The content of the context manager in step S2 specifically includes: Step S201: providing a query channel for microservice context information; Step S202: Obtain the globally unique Tag value of the microservice instance from the control plane global manager and store it in the local Tag value mapping table of the kernel space for the message marker on the node to query and mark the sent message.

5. A method for dynamic access control strategy of microservices under zero trust architecture as described in claim 4, characterized in that: The specific steps of the message marker in step S202 include: Step S2021: the microservice instance sends a message, and the message marker intercepts it to obtain message information; Step S2022: According to the <namespace, source address, source port> information of the message, query the socket meta information table and the local Tag mapping table to obtain the microservice to which the message belongs and the corresponding Tag value; Step S2023: According to the network topology where the microservice is deployed, the Tag value is recorded in the IPOption field or the Vxlan header field to complete the Tag value marking; Step S2024: Send the message marked with the Tag value to the cluster microservice through the node physical network interface.

6. A method for dynamic access control strategy of microservices under zero trust architecture as described in claim 5, characterized in that: The specific steps of the message verifier receiving the message in step S5 are: Step S501: The message verifier receives the message sent by the sending end microservice; Step S502: extract the Tag value from the IP Option or Vxlan header, and query the local Tag value mapping table to determine whether the entry corresponding to the Tag value exists and is valid; Step S503: If the Tag value is valid, obtain the sender microservice namespace value of the Tag value mapping table, query the local context table, obtain the sender microservice context, and continue the decision-making process. If the Tag value is invalid, submit the Tag value to the local context manager to trigger the Tag mapping table synchronization task.

7. A method for dynamic access control strategy of microservices under zero trust architecture as described in claim 6, characterized in that: The specific steps in step S6 are: Step S601: According to the <destination interface, destination IP, destination port> of the message, query the local socket meta-information table to obtain the namespace of the receiving end; Step S602: query the local context table and the local tag mapping table to obtain the context information of the receiving end and the corresponding tag value; Step S603: query the decision cache table. If the decision result does not exist or is expired, query the local decision table, use the iterative strategy table to calculate the decision result and update the decision cache table. The specific formula of strategy π(s) is: π(s)=arg max α ∑ s′,r (r+γv(s′)), Among them, α represents the action, s represents the current state, s′ represents the state after the transfer, r represents the reward when s is transferred, γ represents the discount factor, and v(·) represents the state value function; Step S604: Run the decision algorithm. According to the running result of the decision algorithm, the message verifier releases or discards the message and executes the corresponding permission or rejection access control policy.

8. A method for dynamic access control strategy of microservices under zero trust architecture as described in claim 7, characterized in that: The specific method for implementing the access control strategy in step S604 includes: Step S6041: Obtaining the context information of the microservice runtime through the event tracker deployed in the kernel state; Step S6042: Based on the tag mapping table and the context mapping table, the context of the communication sender does not need to be carried in the communication data flow; Step S6043: The event-based context collection method implements a dynamic execution strategy by setting an expiration event for a context mapping table entry. The specific formula is: L(y,ξ(x,θ))=|ξ(x,θ)-y|<ε, Among them, ξ(·) represents the decision function, θ represents a set of learning parameters, x represents the input tag value data, y represents the output tag value data, L(y,ξ(x,θ)) represents the loss function, and ε is a positive number. The smaller the structured risk, the more complex the decision function of the model. The structured risk function S(ξ) is: Among them, r(θ) represents the number of feature items in the loss function, N represents the number of data, and x i Indicates the i-th input Tag value data, y i represents the i-th output Tag value data, and f(·) represents the mapping function.

9. A microservice dynamic access control policy system under a zero-trust architecture, which is based on a method for implementing a microservice dynamic access control policy under a zero-trust architecture according to any one of claims 1 to 8, characterized in that: include: Microservice scheduling cluster module, service node module and access control module, The microservice scheduling cluster module is used to receive context information transmitted by the context manager and determine whether it is a microservice instance; The service node module is used to map website content and provide website content stored in the nearest server according to the user's region; The access control module is used to support dynamic context collection and distribution, and use access control policies to judge, match and filter the obtained Tag values.

10. A microservice dynamic access control policy system under a zero-trust architecture as claimed in claim 9, characterized in that: The service node module includes a context manager unit, an event tracker unit, a policy agent unit, a message marker unit and a message validator unit. The context manager unit is used to monitor and track microservice kernel events and collect context information associated with the microservice; The event tracker unit is used to collect events reported by the event tracker and aggregate the context information of the microservice instance through <namespace, process Pid>; The policy agent unit is used to obtain access control policies and synchronize them to the local policy table so as to perform fast access policy verification on the node; The message marker unit is used to mark all external data messages of the microservice; The message validator unit is used to release the data message to the target microservice instance or discard the message.

11. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method for implementing a dynamic access control policy for microservices under a zero-trust architecture as described in any one of claims 1-8 are implemented.

12. A computer-readable storage medium, characterized in that: Computer instructions are stored thereon, and when the computer instructions are executed, the steps of a method for dynamic access control strategy of microservices under a zero-trust architecture as described in any one of claims 1-8 are executed.

Images