Method and device for dynamic access control policy of microservice under zero trust architecture

Abstract

The application discloses a kind of microservice dynamic access control strategy under zero trust architecture method and device, belong to network security, distributed system, zero trust, microservice field, it specifically includes: by the event tracker of node to obtain the context information in microservice runtime context event, context manager collects and aggregates context information and is reported to microservice control face global manager, global manager is according to global context mapping table value, judge whether it is new microservice instance, if yes then update global and local Tag mapping table, when node receives message, message verifier obtains the Tag value carried by this message, by local Tag mapping table to obtain the microservice context information corresponding to this message, after inquiring local strategy table and global strategy table, run decision algorithm, execute corresponding access control strategy, use context to identify communication endpoint, with dynamic, accurate, scalable advantage.

Description

Technical Field

[0001] This invention belongs to the fields of network security, distributed systems, zero trust, and microservices. Specifically, it is a method and apparatus for dynamic access control strategies for microservices under a zero trust architecture. Background Technology

[0002] Microservices are a deployment model widely adopted by enterprises in recent years. By dividing a monolithic application into a set of independent functional services, which call each other over the network, microservices provide agile, reliable, and reusable functions, thus providing value to enterprise users.

[0003] Traditional microservice security strategies typically involve deploying firewalls and gateways at the data center entry points of microservices to centrally control access policies. This method primarily relies on building security boundaries at the network perimeter to control north-south traffic. However, with the increasing workload in enterprise data centers and the growing number of internal services calling each other, east-west traffic is constantly increasing. Unsecured internal services become entry points for unauthorized access, allowing security risks to spread internally.

[0004] For example, Chinese patent application CN114519196A discloses a dynamic access control policy evaluation method for microservices, which includes two parts: a policy set simplification and optimization method based on attribute similarity calculation and dynamic access control policy evaluation based on matching tree structure. It mainly targets three stages: policy simplification and optimization, matching tree construction, and dynamic policy evaluation based on matching tree. By using the attribute-based similarity calculation method, access control conflicts and redundant policies are finely divided and resolved, and interference from irrelevant policies is reduced. By constructing the matching tree structure, the efficiency of policy retrieval and matching is improved. At the same time, it supports the maintenance of only the updated part of the policy in the matching tree during the dynamic change of the microservice policy library, while the rest continues to be evaluated, ensuring the secure implementation of microservice access control and protecting the data security of the microservice system.

[0005] For example, Chinese patent application CN113051602A discloses a fine-grained database access control method based on a zero-trust architecture. Its key feature is that the user sends a data access request and a digital certificate to a proxy gateway acting as the policy enforcement point in the zero-trust architecture. The proxy gateway performs authentication and determines whether to continue processing the data access request. Then, the proxy gateway forwards the access request through the zero-trust architecture's policy management process to the policy engine. The policy engine obtains real-time dynamic information and performs trust calculations. Next, the policy engine combines the trust calculation results with static information to generate instantiated access attribute tuples, matches them with access control policies, and determines whether the access is allowed or denied. Finally, the policy manager receives the policy engine's decision information and authorizes the user based on the decision information. The user's access request is then 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 the distributed database.

[0006] The above patents all have the following problems: 1) They require a large amount of computing resources to analyze packets; 2) They require the deployment of firewalls and gateways at the data center entrance of microservices to uniformly control access policies. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention proposes a method and apparatus for dynamic access control policies for microservices under a zero-trust architecture. By using software-defined boundaries, the traditional network device-based boundaries are transformed into software-defined logic. Microservice runtime context events are acquired through the node's event tracker. The context manager collects and aggregates the context information reported by the event tracker, stores and updates the collected and aggregated context information in the local context mapping table. The context manager then reports the aggregated context information to the global manager of the microservice control plane. The global manager then updates the global context mapping table. Based on the value in the global context mapping table, the global manager determines whether it is a newly added microservice instance. If it is, it updates the global tag mapping table and the local tag mapping table. When a node receives a packet, the packet verifier obtains the tag carried by the packet, retrieves the corresponding microservice context information through the local tag mapping table, queries the local policy table and the global policy table, and executes the corresponding allow or deny access control policy.

[0008] To achieve the above objectives, the present invention provides the following technical solution:

[0009] A method for dynamic access control strategies in microservices under a zero-trust architecture includes:

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

[0011] Step S2: Collect and aggregate the context information reported by the event tracker through the context manager, and store and update 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, and the global manager 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 a node receives a message, the message verifier obtains the Tag value carried by the message and retrieves 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 allow or deny 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 a newly created process. The socket event tracker tracks socket creation, listening, and address binding events. The extended event tracker uses a hot-loadable event tracker to achieve dynamic and scalable microservice context collection.

[0017] Specifically, the specific steps of the event tracker implementation in step S1 include:

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

[0019] Step S102: Hot-load the compiled Berkeley package filter bytecode to different kernel hook points;

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

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

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

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

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

[0025] Step S021: The microservice instance sends a message, which is intercepted by the message marker to obtain the message information;

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

[0027] Step S023: Based on the network topology of the deployed microservices, record the Tag value in the IP Option field or Vxlan header field to complete the Tag value marking;

[0028] Step S2024: Send the packets marked with Tag values ​​to the cluster microservices through the node's physical network interface.

[0029] Specifically, the steps for the message verifier to receive the message in step S5 are as follows:

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

[0031] 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 table entry corresponding to the Tag value exists and is valid;

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

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

[0034] Step S601: Based on the <destination interface, destination IP, destination port> in the message, query the local socket metadata table to obtain the namespace of the receiving end;

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

[0036] Step S603: Query the decision cache table. If the decision result does not exist or has expired, query the local decision table, calculate the decision result using the iterative strategy table, and update the decision cache table. The specific formula for strategy π(s) is:

[0037]

[0038] Where α represents the action, s represents the current state, s′ represents the state after the transition, r represents the reward when s transitions, γ represents the depreciation factor, and v(·) represents the state value function;

[0039] Step S604: Run the decision algorithm. Based on the result of the decision algorithm, the message verifier either allows or discards the message and executes the corresponding allow or deny access control policy.

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

[0041] Step S6041: Obtain the runtime context information of the microservice by deploying an event tracker in kernel space;

[0042] 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;

[0043] Step S6043: The event-based context acquisition method implements a dynamic execution strategy by setting expiration events for entries in the context mapping table. The specific formula is as follows:

[0044] L(y,ξ(x,θ))=|ξ(x,θ)-y|<ε,

[0045] Where ξ(·) 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.

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

[0047]

[0048] Where r(θ) represents the number of feature terms in the loss function, N represents the number of data points, and x i This represents the i-th input tag value, y. i Let f(·) represent the i-th output tag value, and f(·) represent the mapping function.

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

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

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

[0052] The access control policy module is used to support dynamic context collection and distribution, and to judge, match and filter the obtained tag values ​​using access control policies.

[0053] Specifically, the service node module includes a context manager unit, an event tracker unit, a policy proxy unit, a message marker unit, and a message verifier unit.

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

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

[0056] The policy proxy unit is used to obtain access control policies and synchronize them to the local policy table so that fast access policy verification can be performed on the node.

[0057] The message tagger unit is used to tag all data messages sent out by the microservice;

[0058] The message verifier unit is used to allow data messages to the target microservice instance or to discard messages.

[0059] Specifically, an electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement a method for a dynamic access control policy for microservices under a zero-trust architecture.

[0060] Specifically, a computer-readable storage medium is characterized by storing computer instructions thereon, which, when executed, perform the steps of a method for implementing a dynamic access control strategy for microservices under a zero-trust architecture.

[0061] Compared with the prior art, the beneficial effects of the present invention are:

[0062] 1. This 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 costs.

[0063] 2. This 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, the context is used to identify communication endpoints, which has the advantages of being dynamic, accurate, and scalable. When the runtime parameters of a microservice instance change, the context parameters collected by the event tracker are updated simultaneously. In this way, the access control policy based on the microservice context can take effect immediately, enhancing security.

[0064] 3. This invention proposes a method for dynamic access control strategies for microservices under a zero-trust architecture. By deploying an event tracker in kernel space, it obtains the runtime context information of the microservices. This not only ensures security but also allows for the deployment of different event trackers as needed to collect more context information, enabling precise definition of the communication endpoint's state. Based on tag mapping tables and context mapping tables, the context of the communication sender does not need to be carried in the communication data stream, offering advantages such as low system resource consumption, good scalability, and support for all communication protocols.

[0065] 4. This invention proposes a method for dynamic access control policies for microservices under a zero-trust architecture. It employs an event-based context collection method and sets expiration events for context mapping table entries, offering advantages such as real-time analysis and dynamic policy execution. Attached Figure Description

[0066] Figure 1 This is a flowchart of a method for dynamic access control strategy of microservices under a zero-trust architecture according to the present invention.

[0067] Figure 2 This invention provides a method for dynamic access control strategies for microservices under a zero-trust architecture, and includes a flowchart of the microservice context information collection and aggregation process.

[0068] Figure 3 This invention provides a method for dynamic access control strategies for microservices under a zero-trust architecture, and includes a flowchart of the microservice message sending process.

[0069] Figure 4 This invention provides a method for dynamic access control strategies for microservices under a zero-trust architecture, and includes a flowchart of the microservice message receiving process.

[0070] Figure 5 This is a system architecture diagram of a microservice dynamic access control strategy under a zero-trust architecture according to the present invention;

[0071] Figure 6 The present invention relates to an electronic device for a method of dynamic access control strategy for microservices under a zero-trust architecture. Detailed Implementation

[0072] To facilitate understanding of the technical means, creative features, and achieved objectives and effects of this invention, it should be noted in the description of this invention that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "number one," "number two," and "number three" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The invention will be further described below in conjunction with specific embodiments.

[0073] Example 1

[0074] Please see Figures 1-4 The present invention provides an embodiment of a method for dynamic access control policies for microservices under a zero-trust architecture, comprising:

[0075] Step S1: Obtain context information from microservice runtime context events through the node's event tracker;

[0076] A node is an edge server that maps website content to a user's location, providing the website content stored on the server closest to the user.

[0077] Event tracers are used to monitor and track kernel events related to microservices and collect context information associated with microservices. They can log kernel and application-defined events to log files for real-time use. Event tracing components are divided into: controllers, providers, and consumers. Controllers define the size and location of log files, start and stop event tracing sessions, and enable providers. Providers contain applications that perform event tracing detection; 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.

[0078] Step S2: Collect and aggregate the context information reported by the event tracker through the context manager, and store and update the collected and aggregated context information to the local context mapping table;

[0079] A context manager is a powerful mechanism for managing resource acquisition and release. It provides a concise and safe way to handle resource opening, closing, and exception handling, making code readable and maintainable while enhancing program robustness. The context manager is also responsible for reporting local context information to the microservice control center to support cross-node access control.

[0080] Step S3: The context manager reports the aggregated context information to the microservice control plane global manager, and the global manager then updates the global context mapping table;

[0081] 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.

[0082] Step S5: When a node receives a message, the message verifier obtains the Tag value carried by the message and retrieves the microservice context information corresponding to the message through the local Tag mapping table;

[0083] Step S6: Query the local policy table and the global policy table, run the decision algorithm, and execute the corresponding allow or deny access control policy.

[0084] The event trackers in step S1 include: 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 a newly created process. The socket event tracker tracks socket creation, listening, and address binding events. The extended event tracker uses a hot-loadable event tracker to achieve dynamic and scalable microservice context collection.

[0085] The process ID can be associated with the context of a specific application process within a microservice, while the namespace value can be associated with all contexts belonging to the same microservice on the same node. Furthermore, the event tracker must be running on every microservice deployment node.

[0086] The specific steps for implementing the event tracker in step S1 include:

[0087] Step S101: Compile the extended Berkeley package filter using just-in-time compilation technology;

[0088] The Extended Berkeley Packet Filter (eBPF) consists of two parts: user space and kernel space. User-space programs need to interact with the kernel through Berkeley Packet Filter (BPF) system calls to complete tasks such as loading eBPF programs, mounting events, and creating and updating mappings. In kernel space, eBPF programs cannot arbitrarily call kernel functions, but need to complete the required tasks through BPF helper functions.

[0089] Just-In-Time (JIT) compilation technology analyzes the execution process and selectively compiles hot-spot code into machine code and caches it. It also employs code optimization techniques during compilation to improve execution efficiency. The main steps of JIT include: 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 offsets of the `jmp` instructions and save them to `insn->imm`; 6) Call `bpf_int_jit_compile` again to correct the `jmp` offsets; 7) Call `bpf_prog_lock_ro` to change the access permissions of each function's code segment to RO; 8) Call `bpf_prog_kallsyms_add` to add the symbol information of each function to kallsyms.

[0090] Step S102: Hot-load the compiled Berkeley package filter bytecode to different kernel hook points;

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

[0092] The context manager in step S2 specifically includes:

[0093] Step S201: Provide a query channel for microservice context information;

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

[0095] Each node's context manager retrieves the microservice tag value mapping table from the global manager and stores it in a local tag value mapping table in the kernel space for the message tagger to query. The key and value of the tag mapping table are: Tag: <namespace, instance ID>.

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

[0097] Step S021: The microservice instance sends a message, which is intercepted by the message marker to obtain the message information;

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

[0099] Step S023: Based on the network topology of the deployed microservices, record the Tag value in the IP Option field or Vxlan header field to complete the Tag value marking;

[0100] Step S2024: Send packets marked with Tag values ​​to the microservices in the cluster through the node's physical network interface.

[0101] The specific steps for the message verifier to receive the message in step S5 are as follows:

[0102] Step S501: The message verifier receives the message sent by the sending microservice;

[0103] Step S502: Extract the Tag value from the IP Option or Vxlan header, and query the local Tag value mapping table to obtain the microservice context information corresponding to the packet;

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

[0105] The specific steps in step S6 are as follows:

[0106] Step S601: Based on the <destination interface, destination IP, destination port> in the message, query the local socket metadata table to obtain the namespace of the receiving end;

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

[0108] Step S603: Query the decision cache table. If the decision result does not exist or has expired, query the local decision table, calculate the decision result using the iterative strategy table, and update the decision cache table. The specific formula for strategy π(s) is:

[0109] π(s) = arg max α ∑ s′,r (r+γv(s′)),

[0110] Where α represents the action, s represents the current state, s′ represents the state after the transition, r represents the reward when s transitions, γ represents the depreciation factor, and v(·) represents the state value function;

[0111] A decision table, also known as a judgment table, is a tabular graphical tool suitable for describing situations with numerous judgment conditions, combinations of these conditions, and multiple decision options. It provides a precise and concise way to describe complex logic, associating multiple conditions with the actions to be performed when these conditions are met. Unlike control statements in traditional programming languages, decision tables clearly represent the direct relationships between multiple independent conditions and multiple actions. A decision table has four parts: condition stubs, action stubs, condition items, and action items.

[0112] A strategy is about deciding what action to take based on the current state. Strategy iteration includes strategy evaluation and strategy improvement. Strategy evaluation determines the effectiveness of a strategy and uses expected value to reflect this. The specific formula for expected value is:

[0113] V(s) = max α ∑ s′,r p(s′,r|s,α)[r+γV(s′)],

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

[0115] Strategy improvement aims to find the best strategy; the specific formula is:

[0116] If we assume that π and π′ are a pair of deterministic strategies, then...

[0117] q π (s,π′(s))≥v π (s),

[0118] Where, q π (·) represents the action-value function, v π (·) represents the state value function of strategy π.

[0119] Step S604: Run the decision algorithm. Based on the algorithm's result, the message verifier either allows or discards the message, executing the corresponding allow or deny access control policy. The specific formula is as follows:

[0120] L(y,ξ(x,θ))=|ξ(x,θ)-y|<ε,

[0121] Where ξ(·) 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 very small positive number.

[0122] Secondly, a structured risk function is calculated to improve the predictive ability for unknown data. The smaller the structured risk, the more complex the model's decision function. The structured risk function is as follows:

[0123]

[0124] Where r(θ) represents the number of feature terms in the loss function, N represents the number of data points, and x i This represents the i-th input tag value, y. i Let f(·) represent the i-th output tag value, and f(·) represent the mapping function.

[0125] The loss function is the foundation 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 true value of the sample. Minimizing empirical risk means minimizing this expression, which is the average minimization of the loss function over all sample points in the training set. A smaller empirical risk indicates a better fit of the model to the training set. However, when the empirical risk function becomes too small, overfitting occurs. This can also be understood as the complexity of the model's decision function being a necessary condition for overfitting.

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

[0127] Step S6041: Obtain the runtime context information of the microservice by deploying an event tracker in kernel space to precisely define the state of the communication endpoints;

[0128] 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 consumption, good scalability, and supports all communication protocols.

[0129] Step S6043: The event-based context collection method, and the expiration event of the context mapping table entries, have the advantages of satisfying real-time analysis and dynamic execution strategies.

[0130] Access control policies are a primary strategy for network security prevention and protection, aiming to prevent unauthorized use and access to network resources. Access control policies include network access control policies, operation permission control policies, directory security control policies, attribute security control policies, network server security control policies, network monitoring, lockout 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 are authorized to use network resources, and controls the time and location of user access. Operation permission control takes security protection measures against possible unauthorized network operations. Directory security allows user operations at the directory level to be effective for all files and subdirectories within that directory. Attribute security control policies allow associating set access attributes 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 damaging data. The network server should log user access to network resources. For unauthorized network access, the server should issue alerts in the form of graphics, text, or sound. A firewall is a technical measure to protect computer network security and serves as a barrier to prevent hackers from entering the enterprise intranet.

[0131] Example 2

[0132] Please see Figure 5 Another embodiment of the present invention provides: 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.

[0133] The microservice scheduling cluster module is mainly the 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.

[0134] The service node module includes a user space and a kernel space, which are used to map website content and provide the website content stored in the nearest server according to the user's region.

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

[0136] The service node module includes a context manager unit, an event tracker unit, a policy proxy unit, a message marker unit, and a message verifier unit.

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

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

[0139] The policy proxy unit is used to obtain access control policies and synchronize them to the local policy table so that fast access policy verification can be performed on the node.

[0140] The message tagger unit is used to tag all data messages sent out by the microservice;

[0141] The message verifier unit is used to allow data messages to the target microservice instance or to discard messages.

[0142] Example 3

[0143] Please see Figure 6 An electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement a method for a dynamic access control policy for microservices under a zero-trust architecture.

[0144] A computer-readable storage medium is characterized in that it stores computer instructions thereon, and when the computer instructions are executed, it executes a method for implementing a dynamic access control strategy for microservices under a zero-trust architecture.

[0145] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0146] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0147] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0148] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0149] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims. All of these forms are within the protection scope of the present invention.

Claims

1. A method for dynamic access control strategies in microservices under a zero-trust architecture, characterized in that, include: Step S1: Obtain context information from microservice runtime context events through the node's event tracker; Step S2: Collect and aggregate the context information reported by the event tracker through the context manager, and store and update 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 then 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 a node receives a message, the message verifier obtains the Tag value carried by the message and retrieves 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 allow or deny access control policy; The specific steps in step S6 are as follows: Step S601: Based on the <destination interface, destination IP, destination port> in the message, query the local socket metadata table to obtain the namespace of the receiving end; Step S602: Query the local context table and local tag mapping table to obtain the context information and corresponding tag value of the receiving end; Step S603: Query the decision cache table. If the decision result does not exist or has expired, query the local decision table, calculate the decision result using the iterative strategy table, and update the decision cache table. The specific formula is as follows: ， in, s represents the action, and s represents the current state. Indicates the state after the transition. This represents the reward when s is transferred. Indicates the loss factor. Represents the state value function; Step S604: Run the decision algorithm. Based on the result of the decision algorithm, the message verifier either allows or discards the message and executes the corresponding allow or deny access control policy.

2. The method for dynamic access control strategy of microservices under a 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 a newly created process. The socket event tracker tracks socket creation, listening, and address binding events. The extended event tracker uses a hot-loadable event tracker to achieve dynamic and scalable microservice context collection.

3. The method for dynamic access control strategy of microservices under a zero-trust architecture as described in claim 2, characterized in that, The specific steps implemented by the event tracker in step S1 include: Step S101: Compile the extended Berkeley package filter using just-in-time compilation technology; Step S102: Hot-load the compiled Berkeley package filter bytecode to different kernel hook points; Step S103: Complete the collection of kernel events and report them to user space.

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

5. The method for dynamic access control strategy of microservices under a zero-trust architecture as described in claim 4, characterized in that, The specific steps of the message marker in step S202 include: Step S021: The microservice instance sends a message, which is intercepted by the message marker to obtain the message information; Step S2022: Based on the <namespace, source address, source port> information of the message, query the socket metadata table and the local tag mapping table to obtain the microservice to which the message belongs and the corresponding tag value; Step S2023: Based on the network topology of the deployed microservices, record the Tag value in the IPOPtion field or Vxlan header field to complete the Tag value marking; Step S2024: Send the packets marked with Tag values ​​to the cluster microservices through the node's physical network interface.

6. The method for dynamic access control strategy of microservices under a zero-trust architecture as described in claim 5, characterized in that, The specific steps for the message verifier to receive the message in step S5 are as follows: Step S501: The message verifier receives the message sent by the sending 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 table entry corresponding to the Tag value exists and is valid; Step S503: If the Tag value is valid, obtain the namespace value of the sending microservice in the Tag value mapping table, query the local context table, obtain the sending microservice context, and continue the decision process. If the Tag value is invalid, submit the Tag value to the local context manager and trigger the Tag mapping table synchronization task.

7. The method for dynamic access control strategy of microservices under a zero-trust architecture as described in claim 6, characterized in that, The specific methods for implementing the access control policy in step S604 include: Step S6041: Obtain the runtime context information of the microservice by deploying an event tracker in kernel space; 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; Step S6043: The event-based context acquisition method implements a dynamic execution strategy by setting expiration events for entries in the context mapping table. The specific formula is as follows: ， in, Represents the decision function. Represents a set of learning parameters, This indicates the input tag value data. This indicates that the Tag value data will be output. Represents the loss function. It is a positive number. The smaller the structured risk, the more complex the model's decision function, and the more complex the structured risk function. for: ， in, This represents the number of feature terms in the loss function. Indicates the number of data points. This represents the i-th input tag value. This represents the i-th output tag value. This represents a mapping function.

8. A dynamic access control policy system for microservices under a zero-trust architecture, implemented based on the method of dynamic access control policy for microservices under a zero-trust architecture as described in any one of claims 1-7, characterized in that... include: The microservice scheduling cluster module, service node module, and access control module are included. 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 the 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 to judge, match and filter the obtained tag values ​​using access control policies.

9. A microservice dynamic access control policy system under a zero-trust architecture as described in claim 8, characterized in that, The service node module includes a context manager unit, an event tracker unit, a policy proxy unit, a message marker unit, and a message verifier 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 microservice instances through <namespace, process Pid>. The policy proxy unit is used to obtain access control policies and synchronize them to the local policy table so that fast access policy verification can be performed on the node. The message tagger unit is used to tag all data messages sent out by the microservice; The message verifier unit is used to allow data messages to the target microservice instance or to discard messages.

10. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of a method for a microservice dynamic access control strategy under a zero-trust architecture as described in any one of claims 1-7.

11. A computer-readable storage medium, characterized in that, It stores computer instructions, which, when executed, perform the steps of a method for a microservice dynamic access control strategy under a zero-trust architecture as described in any one of claims 1-7.

Images