Kubernetes and istio-based zero-intrusion microservice permission control method and system

Abstract

The present application relates to a Kubernetes and Istio-based non-invasive microservice permission control method, comprising the following: obtaining a permission policy defined by a file configured by an administrator, and storing the permission policy in a Kubernetes cluster in the form of CRD; performing policy change listening through an Istio control plane, and when a permission change is listened to, dynamically issuing to an Envoy agent of a related microservice through a Sidecar injection mechanism; when any microservice A in the Kubernetes cluster issues a request for calling other microservice B, the request is intercepted, features are extracted based on the request, the extracted features are matched and verified with the permission policy, if the verification is passed, the request is released, and if the verification is not passed, the request is not released and a reminder is given. The present application can realize fine-grained access control on the calling between microservices, without modifying business code or restarting services. The present application is suitable for microservice security governance in a cloud-native environment.

Description

Technical Field

[0001] This invention relates to the field of microservice security technology, and in particular to a zero-intrusion microservice access control method and system based on Kubernetes and Istio. Background Technology

[0002] In a microservice architecture, access control for inter-service calls is typically implemented through hard-coded code or a gateway layer, which presents the following problems: (1) Highly invasive: It requires modification of business code, increasing development and maintenance costs; (2) Difficulty in updating strategies: Service restart or redeployment is required; (3) Coarse granularity: It is difficult to achieve fine-grained control at the API level; (4) Audit difficulties: There is a lack of unified logs and monitoring for authority decisions.

[0003] Existing Istio-based solutions mostly focus on traffic management, have limited access control capabilities, and lack an integrated mechanism for dynamic policy injection and auditing.

[0004] Based on the above problems, the following improvement solutions exist. (1) Using an API gateway to centrally control permissions can introduce single-point bottlenecks and configuration complexity; (2) Integrating the permission SDK into the business code is highly intrusive and difficult to update; (3) Using traditional firewalls or network policies, but with coarse granularity, they cannot identify application layer protocols. Summary of the Invention

[0005] The purpose of this invention is to at least address one of the shortcomings of the prior art by providing a zero-intrusion microservice access control method and system based on Kubernetes and Istio.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: Specifically, a zero-intrusion microservice access control method based on Kubernetes and Istio is proposed, including the following: Obtain the file permission policy configured by the administrator and store the permission policy in the Kubernetes cluster in the form of a CRD; The policy change is monitored through the Istio control plane. When the Istio control plane detects the permission policy in the Kubernetes cluster, it converts the permission policy into a preset format and then dynamically distributes it to the Envoy proxy of the relevant microservice through the Sidecar injection mechanism. When any microservice A in the Kubernetes cluster sends a request to call another microservice B, it is intercepted by the Envoy Sidecar of microservice A, and feature extraction is performed on the request. The extracted features are matched and verified with the permission policy. If the verification is successful, the request is allowed; if the verification fails, the request is denied and a warning is issued.

[0007] Furthermore, the method also includes, After each permission policy matching and verification is completed, the result is recorded in a structured audit log for subsequent analysis.

[0008] Furthermore, the Envoy proxy is dynamically distributed to the relevant microservices via the Sidecar injection mechanism, including... The permission policy in the preset format is gradually distributed to local microservices in a preset step size. After each distribution, the local microservices are monitored for abnormalities. If an abnormality is found, the local microservices distributed in the current distribution are rolled back, that is, the old policy before the update is switched back.

[0009] Furthermore, the process of extracting features based on the request and matching and verifying the extracted features with the permission policy includes, Based on the request, communication features, environmental identity features, and dynamic environmental features are extracted, and the extracted features are integrated to obtain the original comprehensive feature set F_raw; The request is subjected to streaming incremental parsing to obtain the business semantic feature F_payload; Using F_raw and F_payload as data inputs, the data inputs are subjected to sensitive feature identification and privacy protection processing to obtain the feature set F_secure; Feature normalization and cache optimization are performed on F_secure to obtain the standard feature vector F_vector; The F_vector is matched with the permission policy in the form of a locally cached CRD to obtain the matching result.

[0010] Furthermore, specifically, based on the request, communication features, environmental identity features, and dynamic environmental features are extracted, including: The communication features, namely request method, request path, query parameters, key request headers and protocol type, are extracted from the message of the request. The environmental identity features, namely source service name, namespace, Pod tag and workload identity SPIFFE ID, are obtained from the metadata of the Envoy Sidecar of microservice A. The dynamic environmental features, namely request initiation timestamp, node availability zone, cluster ID and trace information Trace ID and / or Span ID, are obtained from the system context.

[0011] Furthermore, specifically, the request is subjected to streaming incremental parsing to obtain the business semantic feature F_payload, including, Obtain the original byte stream of the request, match only the preset key fields in the preset path according to the pre-configured extraction rules, immediately extract the field values ​​and discard the remaining data stream after all the preset key fields are matched, and use the matched key fields as the business semantic feature F_payload.

[0012] Furthermore, specifically, using F_raw and F_payload as data input, sensitive feature identification and privacy protection processing are performed on the data input to obtain a feature set F_secure, including: Sensitive fields are obtained by matching the input data with sensitive fields according to a preset rule base. Irreversible hashing is performed on sensitive fields, and RESTful path parameters are desensitized, while the remaining non-sensitive fields are directly retained to obtain the feature set F_secure.

[0013] Furthermore, specifically, feature normalization and cache optimization are performed on F_secure to obtain the standard feature vector F_vector, including, F_secure is formatted as a KV key-value structure and a cache key is generated. Then, the local LRU cache is queried. If a match is found, the calculated feature vector is directly reused as the standard feature vector F_vector. If no match is found, the feature vector is transformed to obtain the standard feature vector F_vector and written to the local LRU cache.

[0014] Furthermore, the method also includes returning a preset permission error code as an alarm when the verification fails.

[0015] This invention also proposes a zero-intrusive microservice permission control device based on Kubernetes and Istio, comprising the following: The policy acquisition module is used to acquire the permission policies for file definitions configured by the administrator and store the permission policies in the Kubernetes cluster in the form of CRD; The policy delivery module is used to listen for policy changes through the Istio control plane. When the Istio control plane listens for the permission policy in the Kubernetes cluster, it converts the permission policy into a preset format and then dynamically delivers it to the Envoy proxy of the relevant microservice through the Sidecar injection mechanism. The policy enforcement module is used to intercept requests from any microservice A in the Kubernetes cluster to call other microservice B through the Envoy Sidecar of microservice A, extract features based on the request, and match and verify the extracted features with the permission policy. If the verification is successful, the request is allowed; if the verification fails, the request is denied and a warning is issued.

[0016] The beneficial effects of this invention are as follows: This invention proposes a zero-intrusion microservice access control method and apparatus based on Kubernetes and Istio. It uses the Istio control plane to monitor policy changes. When a permission policy change is detected in the Kubernetes cluster, it dynamically distributes the change to the Envoy proxy of the relevant microservice via a sidecar injection mechanism. The permission policy is then dynamically injected and executed at the service mesh layer, achieving fine-grained access control for inter-microservice calls without requiring modification of business code or service restarts. This invention is applicable to microservice security governance in cloud-native environments. Attached Figure Description

[0017] The above and other features of this disclosure will become more apparent from the detailed description of the embodiments illustrated in conjunction with the accompanying drawings. In the accompanying drawings, the same reference numerals denote the same or similar elements. Obviously, the drawings described below are merely some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained from these drawings without any creative effort. In the drawings: Figure 1 The diagram shows a flowchart of the zero-intrusion microservice permission control method based on Kubernetes and Istio according to the present invention. Figure 2 The diagram shown is the left part of the architecture of the zero-intrusion microservice permission control system based on Kubernetes and Istio of this invention. Figure 3 The diagram shown is the right part of the architecture of the zero-intrusion microservice permission control system based on Kubernetes and Istio of this invention. Detailed Implementation

[0018] The following will provide a clear and complete description of the concept, specific structure, and technical effects of the present invention in conjunction with embodiments and accompanying drawings, so as to fully understand the purpose, solution, and effects of the present invention. It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The same reference numerals used throughout the accompanying drawings indicate the same or similar parts.

[0019] Example 1, referring to Figure 1This invention proposes a zero-intrusive microservice access control method based on Kubernetes and Istio, including the following: Obtain the file permission policy configured by the administrator and store the permission policy in the Kubernetes cluster in the form of a CRD; The policy change is monitored through the Istio control plane. When the Istio control plane detects the permission policy in the Kubernetes cluster, it converts the permission policy into a preset format and then dynamically distributes it to the Envoy proxy of the relevant microservice through the Sidecar injection mechanism. When any microservice A in the Kubernetes cluster sends a request to call another microservice B, it is intercepted by the Envoy Sidecar of microservice A, and feature extraction is performed on the request. The extracted features are matched and verified with the permission policy. If the verification is successful, the request is allowed; if the verification fails, the request is denied and a warning is issued.

[0020] In this embodiment 1, policy change monitoring is performed through the Istio control plane. When a permission policy change is detected in the Kubernetes cluster, it is dynamically distributed to the Envoy proxy of the relevant microservice via the Sidecar injection mechanism. The permission policy is then dynamically injected and executed at the service mesh layer, achieving fine-grained access control for inter-microservice calls without requiring modification of business code or service restarts. This invention is applicable to microservice security governance in cloud-native environments.

[0021] In a preferred embodiment of the present invention, the method further includes, After each permission policy matching and verification is completed, the result is recorded in a structured audit log for subsequent analysis.

[0022] In this preferred embodiment, all permission verification results (including pass / deny) are recorded in a structured audit log and can be pushed to the monitoring system in real time. Log-based permission anomaly detection and alerts are supported.

[0023] In a preferred embodiment of the present invention, the Envoy proxy for the relevant microservice is dynamically distributed via the Sidecar injection mechanism, including... The permission policy in the preset format is gradually distributed to local microservices in a preset step size. After each distribution, the local microservices are monitored for abnormalities. If an abnormality is found, the local microservices distributed in the current distribution are rolled back, that is, the old policy before the update is switched back.

[0024] In this preferred embodiment, a hot update and canary release mechanism for permission policies is supported. Policies can be distributed to designated service instances in batches through the Kubernetes label selector to achieve smooth changes and rollbacks.

[0025] In a preferred embodiment of the present invention, the process of extracting features based on the request and matching and verifying the extracted features with the permission policy includes: Based on the request, communication features, environmental identity features, and dynamic environmental features are extracted, and the extracted features are integrated to obtain the original comprehensive feature set F_raw; The request is subjected to streaming incremental parsing to obtain the business semantic feature F_payload; Using F_raw and F_payload as data inputs, the data inputs are subjected to sensitive feature identification and privacy protection processing to obtain the feature set F_secure; Feature normalization and cache optimization are performed on F_secure to obtain the standard feature vector F_vector; The F_vector is matched with the permission policy in the form of a locally cached CRD to obtain the matching result.

[0026] In a preferred embodiment of the present invention, specifically, communication features, environmental identity features, and dynamic environmental features are extracted based on the request, including... The communication features, namely request method, request path, query parameters, key request headers and protocol type, are extracted from the message of the request. The environmental identity features, namely source service name, namespace, Pod tag and workload identity SPIFFE ID, are obtained from the metadata of the Envoy Sidecar of microservice A. The dynamic environmental features, namely request initiation timestamp, node availability zone, cluster ID and trace information Trace ID and / or Span ID, are obtained from the system context.

[0027] In a preferred embodiment of the present invention, specifically, the request is subjected to streaming incremental parsing to obtain the business semantic feature F_payload, including, Obtain the original byte stream of the request, match only the preset key fields in the preset path according to the pre-configured extraction rules, immediately extract the field values ​​and discard the remaining data stream after all the preset key fields are matched, and use the matched key fields as the business semantic feature F_payload.

[0028] In a preferred embodiment of the present invention, specifically, using F_raw and F_payload as data inputs, sensitive feature identification and privacy protection processing are performed on the data inputs to obtain a feature set F_secure, including, Sensitive fields are obtained by matching the input data with sensitive fields according to a preset rule base. Irreversible hashing is performed on sensitive fields (i.e., sensitive fields are converted into field values ​​using the SHA256 algorithm, and a dynamic salt value S is added to the field value. The salt value S is issued periodically by Issue and updated hourly, making it impossible to reverse the original value), and the RESTful path parameters are desensitized. The remaining non-sensitive fields are directly retained to obtain the feature set F_secure.

[0029] In a preferred embodiment of the present invention, specifically, feature normalization and cache optimization are performed on F_secure to obtain a standard feature vector F_vector, including, F_secure is formatted as a KV key-value structure and a cache key is generated. Then, the local LRU cache is queried. If a match is found, the calculated feature vector is directly reused as the standard feature vector F_vector. If no match is found, the feature vector is transformed to obtain the standard feature vector F_vector and written to the local LRU cache.

[0030] When this preferred implementation is applied, Multi-dimensional feature structured acquisition: Simultaneously, features are drawn from three sources in parallel to form the original feature set.

[0031] Obtain communication characteristics from request messages (direct parsing). Obtain and structure: Request methods: GET / POST / PUT / DELETE Request path: / api / v1 / order Query parameters: userId=1001&type=express Key request headers: Authorization, X-User-ID, X-Tenant-ID, X-Request-ID. Protocol types: HTTP / 1.1, HTTP / 2, gRPC Output: {method, path, query, headers, protocol}, Retrieve environment identity features from Sidecar metadata (Envoy dynamic metadata retrieval). Obtained via Node Metadata injected by Istio and the Downward API: Source service name: serviceaccount:default / service-a Namespace: ns:order Pod tags: app=service-a, env=prod, region=cn-north Workload identity SPIFFE ID: spiffe: / / cluster.local / ns / default / sa / service-a Output: {source_service, ns, sa, pod_labels, spiffe_id} Obtain dynamic environment characteristics from the system context. Request initiation timestamp (accurate to milliseconds). Node availability zone, cluster ID Link tracing information (Trace ID, Span ID). Output: {timestamp, zone, trace_id} Final output: The original comprehensive feature set F_raw contains three types of structured data: communication features, identity features, and environmental features.

[0032] Streaming request body parsing For large request bodies and JSON / gRPC messages, instead of full loading, incremental streaming parsing is used.

[0033] Data acquisition Obtain the raw byte stream of the request body, provided by Envoy in buffer fragments.

[0034] Processing logic, Start the streaming parser and read data frame by frame.

[0035] Based on the pre-configured extraction rules (JSONPath / Protobuf path), only the required key fields are matched: $.userId, $.orderType, $.tenantId, Once the target field is matched, the field value is extracted immediately and the rest of the data stream is discarded.

[0036] The output business semantic feature F_payload only contains the key fields required for configuration and does not carry the complete request body.

[0037] Sensitive feature identification and privacy protection processing Data input: raw composite features F_raw + business semantic features F_payload Processing flow Sensitive field matching is based on the built-in rule base: User ID, mobile phone number, email address, ID card number, order number, bank card number, Tenant ID, Enterprise ID, and other business-sensitive identifiers, Irreversible hashing is performed on sensitive fields: H = SHA256 (field value + dynamic salt value S). The salt value S is issued periodically by Issued and updated hourly, making it impossible to deduce the original value.

[0038] Path generalization handles parameter desensitization in RESTful paths: for example, converting / user / 123456 to / user / {user_id}. Non-sensitive fields such as method, path, and service are retained in plaintext and are directly preserved.

[0039] The output privacy-preserving feature set F_secure contains hash values ​​for all sensitive content, with no original plaintext.

[0040] Feature normalization and cache optimization Enter F_secure, The process involves formatting all features into a unified key-value structure. Generate cache keys: for example, Key = Hash(source_service + path + method + timestamp_minute). Query local LRU cache: If a match is found, the previously calculated feature vector is reused directly. If a match is not found, the process continues and the data is written to the cache.

[0041] Output the standard feature vector F_vector.

[0042] Feature collection is performed from three sources, and streaming incremental parsing avoids performance bottlenecks caused by large request volumes, effectively solving latency and memory consumption issues in high-concurrency, high-data-volume scenarios. It also automatically identifies sensitive fields and combines them with dynamic salt hashing to form a new security enhancement method in service mesh permission control scenarios, balancing permission verification and data privacy compliance. By using local caching and feature normalization, it achieves real-time permission judgment under low latency and high concurrency, improving the overall system performance. The entire process does not require modification of business code or intrusion into application logic. While maintaining the original advantages of the Istio architecture, it significantly improves the microservice permission control capabilities and security level.

[0043] In a preferred embodiment of the present invention, the method further includes returning a preset permission error code as an alarm when the verification fails.

[0044] Reference Figure 2 as well as Figure 3 ,Will Figure 2 and Figure 3 By piecing together the overlapping parts, we obtain the architecture diagram of the zero-intrusion microservice access control system based on Kubernetes and Istio of this invention. This includes a policy management component, an Istio control plane (Istio), a policy repository (CRD), an Envoy Sidecar proxy layer, inter-microservice communication flow, and an audit log system. Arrows indicate the direction of data flow and control flow; separating them prevents unclear screenshots due to large image sizes. This invention also proposes a zero-intrusion microservice access control device based on Kubernetes and Istio, including the following: The policy acquisition module is used to acquire the permission policies for file definitions configured by the administrator and store the permission policies in the Kubernetes cluster in the form of CRD; The policy delivery module is used to listen for policy changes through the Istio control plane. When the Istio control plane listens for the permission policy in the Kubernetes cluster, it converts the permission policy into a preset format and then dynamically delivers it to the Envoy proxy of the relevant microservice through the Sidecar injection mechanism. The policy enforcement module is used to intercept requests from any microservice A in the Kubernetes cluster to call other microservice B through the Envoy Sidecar of microservice A, extract features based on the request, and match and verify the extracted features with the permission policy. If the verification is successful, the request is allowed; if the verification fails, the request is denied and a warning is issued.

[0045] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment, depending on actual needs.

[0046] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0047] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or system capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0048] Although the description of the invention has been quite detailed and particularly of several described embodiments, it is not intended to limit it to any of these details or embodiments or any particular embodiment, but should be considered as providing a broad possible interpretation of the claims by referring to the appended claims and taking into account the prior art, thereby effectively covering the intended scope of the invention. Furthermore, the invention has been described above with respect to embodiments foreseeable by the inventors in order to provide a useful description, and non-substantial modifications to the invention that have not yet been foreseen may still represent equivalent modifications.

[0049] The above description is merely a preferred embodiment of the present invention. The present invention is not limited to the above-described embodiments. Any embodiment that achieves the technical effects of the present invention using the same means should fall within the protection scope of the present invention. Within the protection scope of the present invention, various modifications and variations can be made to the technical solutions and / or implementation methods.

Claims

1. A zero-intrusive microservice access control method based on Kubernetes and Istio, characterized in that, Including the following: Obtain the file permission policy configured by the administrator and store the permission policy in the Kubernetes cluster in the form of a CRD; The policy change is monitored through the Istio control plane. When the Istio control plane detects the permission policy in the Kubernetes cluster, it converts the permission policy into a preset format and then dynamically distributes it to the Envoy proxy of the relevant microservice through the Sidecar injection mechanism. When any microservice A in the Kubernetes cluster sends a request to call another microservice B, it is intercepted by the Envoy Sidecar of microservice A, and feature extraction is performed on the request. The extracted features are matched and verified with the permission policy. If the verification is successful, the request is allowed; if the verification fails, the request is denied and a warning is issued.

2. The zero-intrusive microservice access control method based on Kubernetes and Istio according to claim 1, characterized in that, The method also includes, After each permission policy matching and verification is completed, the result is recorded in a structured audit log for subsequent analysis.

3. The zero-intrusive microservice access control method based on Kubernetes and Istio according to claim 1, characterized in that, The Envoy proxy is dynamically distributed to the relevant microservices via the Sidecar injection mechanism. include, The permission policy in the preset format is gradually distributed to local microservices in a preset step size. After each distribution, the local microservices are monitored for abnormalities. If an abnormality is found, the local microservices distributed in the current distribution are rolled back, that is, the old policy before the update is switched back.

4. The zero-intrusive microservice access control method based on Kubernetes and Istio according to claim 1, characterized in that, The process of extracting features based on the request and matching and verifying the extracted features with the permission policy includes: Based on the request, communication features, environmental identity features, and dynamic environmental features are extracted, and the extracted features are integrated to obtain the original comprehensive feature set F_raw; The request is subjected to streaming incremental parsing to obtain the business semantic feature F_payload; Using F_raw and F_payload as data inputs, the data inputs are subjected to sensitive feature identification and privacy protection processing to obtain the feature set F_secure; Feature normalization and cache optimization are performed on F_secure to obtain the standard feature vector F_vector; The F_vector is matched with the permission policy in the form of a locally cached CRD to obtain the matching result.

5. The zero-intrusive microservice access control method based on Kubernetes and Istio according to claim 4, characterized in that, Specifically, communication features, environmental identity features, and dynamic environmental features are extracted based on the request. include, The communication features, namely request method, request path, query parameters, key request headers and protocol type, are extracted from the message of the request. The environmental identity features, namely source service name, namespace, Pod tag and workload identity SPIFFE ID, are obtained from the metadata of the Envoy Sidecar of microservice A. The dynamic environmental features, namely request initiation timestamp, node availability zone, cluster ID and trace information Trace ID and / or Span ID, are obtained from the system context.

6. The zero-intrusive microservice access control method based on Kubernetes and Istio according to claim 4, characterized in that, Specifically, the request is subjected to streaming incremental parsing to obtain the business semantic feature F_payload, including: Obtain the original byte stream of the request, match only the preset key fields in the preset path according to the pre-configured extraction rules, immediately extract the field values ​​and discard the remaining data stream after all the preset key fields are matched, and use the matched key fields as the business semantic feature F_payload.

7. The zero-intrusive microservice access control method based on Kubernetes and Istio according to claim 4, characterized in that, Specifically, using F_raw and F_payload as data input, sensitive feature identification and privacy protection processing are performed on the data input to obtain a feature set F_secure, including: Sensitive fields are obtained by matching the input data with sensitive fields according to a preset rule base. Irreversible hashing is performed on sensitive fields, and RESTful path parameters are desensitized, while the remaining non-sensitive fields are directly retained to obtain the feature set F_secure.

8. The zero-intrusive microservice access control method based on Kubernetes and Istio according to claim 4, characterized in that, Specifically, feature normalization and cache optimization are performed on F_secure to obtain the standard feature vector F_vector, including, F_secure is formatted as a KV key-value structure and a cache key is generated. Then, the local LRU cache is queried. If a match is found, the calculated feature vector is directly reused as the standard feature vector F_vector. If no match is found, the feature vector is transformed to obtain the standard feature vector F_vector and written to the local LRU cache.

9. The zero-intrusive microservice access control method based on Kubernetes and Istio according to claim 1, characterized in that, The method also includes returning a preset permission error code as an alarm when verification fails.

10. A zero-intrusive microservice access control device based on Kubernetes and Istio, characterized in that, Including the following: The policy acquisition module is used to acquire the permission policies for file definitions configured by the administrator and store the permission policies in the Kubernetes cluster in the form of CRD; The policy delivery module is used to listen for policy changes through the Istio control plane. When the Istio control plane listens for the permission policy in the Kubernetes cluster, it converts the permission policy into a preset format and then dynamically delivers it to the Envoy proxy of the relevant microservice through the Sidecar injection mechanism. The policy enforcement module is used to intercept requests from any microservice A in the Kubernetes cluster to call other microservice B through the Envoy Sidecar of microservice A, extract features based on the request, and match and verify the extracted features with the permission policy. If the verification is successful, the request is allowed; if the verification fails, the request is denied and a warning is issued.

Images