Network authentication method and device based on istio and OPA, computer device and computer readable storage medium

Abstract

The application relates to a network authentication method and device based on ISTIO and OPA, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: deploying a service agent Envoy and an OPA Agent in a Pod which is a minimum deployment unit containing OPA in a sidecar mode; generating a Service Entry resource and an Extension Provider resource by configuring Istio, and opening a business port of OPA; customizing the content and effective range of the authentication strategy of OPA by configuring an OPA Policy resource; synchronizing the authentication strategy to the corresponding Pod in a multi-cluster environment by using a synchronous compensation mechanism; constructing an inverted index, and mapping the label of each authentication strategy to a resource list with the corresponding label; and in the case of needing to find a resource with a preset label, querying the inverted index to obtain the corresponding resource list. By using the method, the calculation, distribution and retrieval of the strategy can be automatically managed and optimized, so that the network authentication process is more efficient, flexible and easy to manage.

Description

Technical Field

[0001] This application relates to the field of microservices technology, and in particular to a network authentication method, apparatus, computer device, computer-readable storage medium, and computer program product based on ISTIO and OPA. Background Technology

[0002] In modern cloud computing and microservice architectures, the security and effective management of inter-service communication have become crucial issues. With the rapid development of cloud-native technologies, the Service Mesh architecture has emerged, providing a dedicated infrastructure layer for handling inter-service communication. The primary responsibility of the Service Mesh is to ensure reliable request transmission within complex service topologies and to decentralize service governance capabilities, allowing business logic to focus more on core functionalities.

[0003] Istio is one of the more popular service mesh implementations, providing a unified way to manage, monitor, and secure communication between microservices. Logically, Istio is divided into a data plane and a control plane. The data plane, primarily composed of the Envoy proxy, handles the actual traffic between services, including traffic forwarding, routing, and health checks. The control plane manages and configures the proxy to route traffic, including configuring authentication policies, authorization policies, and secure naming information. Istio's security components include a Certificate Authority (CA) for key and certificate management, and Sidecar and Edge proxies as Policy Enforcement Points (PEPs) to protect communication security between clients and servers. Furthermore, the Envoy proxy extension is used for managing telemetry and auditing.

[0004] OPA is a lightweight, general-purpose policy engine that coexists with services, delegating policy decisions to OPA by executing queries. Services provide structured data (such as JSON) as input, and OPA evaluates this policy and data to generate query results. Policies are written in a high-level declarative language and can be dynamically loaded into OPA remotely via API or the local file system. OPA's operation separates policy decision-making from policy implementation, allowing software to query OPA and provide structured data as input when policy decisions are needed. This flexibility and dynamism make OPA an ideal tool for managing complex policy decisions.

[0005] While Istio and OPA each offer powerful features, combining them in practice presents some challenges. Community-provided solutions typically require manual configuration of EnvoyFilter, OPA startup parameters, and authentication policies. This not only increases the barrier to entry but also makes it difficult to adapt to the diverse policies and namespaces required in large service meshes.

[0006] Therefore, there is an urgent need for a network authentication method, device, computer equipment, computer-readable storage medium, and computer program product based on ISTIO and OPA, which aims to make the network authentication process more efficient, flexible, and easy to manage by automating the calculation, distribution, and retrieval of management and optimization strategies. Summary of the Invention

[0007] Therefore, it is necessary to provide a network authentication method, apparatus, computer equipment, computer-readable storage medium, and computer program product based on ISTIO and OPA that can make the network authentication process more efficient, flexible, and easy to manage by automating the calculation, distribution, and retrieval of strategies.

[0008] Firstly, this application provides a network authentication method based on ISTIO and OPA, including:

[0009] In the smallest deployment unit containing OPA, the Pod, deploy the service agent Envoy and the OPA Agent in sidecar mode;

[0010] Pre-configure ServiceEntry and ExtensionProvider resources to enable Envoy to pass traffic to OPAAgent for authentication;

[0011] By configuring OPA Policy resources, you can customize the content and scope of OPA authentication policies.

[0012] By utilizing a synchronization compensation mechanism, the authentication policy is synchronized to the corresponding Pod in a multi-cluster environment;

[0013] When the system is started or updated periodically, an inverted index is built to map the label of each authentication policy to a list of resources with the corresponding label.

[0014] When it is necessary to find resources with preset tags, the inverted index is queried to obtain the corresponding resource list.

[0015] In one embodiment, the method further includes:

[0016] In the smallest deployment unit Pod containing OPA, during the deployment of the service agent Envoy and OPA Agent in sidecar mode, the Config Map resource is removed through the OPA sidecar, and the listening address and policy evaluation path of OPA are configured through container startup parameters.

[0017] In one embodiment, the provisioning of ServiceEntry and ExtensionProvider resources to enable Envoy to pass traffic to the OPA Agent for authentication includes:

[0018] Services are defined through Service Entry resources, specifying the hostname and port of the service entry point so that Istio can route traffic to OPA;

[0019] Enable the OPA service port and configure Envoy through the Extension Provider resource so that Envoy can transfer the decision authority for authentication traffic to the OPA sidecar.

[0020] Configure access control policies in Istio through the Authorization Policy resource, specify the services that need to be checked for OPA authorization, and reference the OPA services defined in the Extension Provider resource.

[0021] In one embodiment, the OPA Policy resource includes an OPA Policy Spec structure; the step of customizing the content and scope of the OPA authentication policy by configuring the OPA Policy resource includes:

[0022] By configuring the OPA Policy Spec structure, the workload selector and authentication policy fields are determined; wherein, the workload selector includes a namespace isolator and a Kubernetes label selector, both of which are used to specify the scope of the authentication policy; the authentication policy fields include policy content written in Rego syntax.

[0023] In one embodiment, the step of using a synchronization compensation mechanism to synchronize the authentication policy to the corresponding Pod in a multi-cluster environment includes:

[0024] The OPA controller listens for add, delete, and modify events of OPA Policy resources and synchronizes any abnormal events in these events to the affected Pods.

[0025] When a Pod is started, an authentication policy set related to the corresponding Pod is generated by the OPA controller based on the Pod tag, and the authentication policy set is filtered.

[0026] In the event of an OPA controller restart, network problems, or other abnormal situations, the authentication policy status is updated periodically through the OPA controller so that the authentication policy is synchronized to the corresponding Pod in a multi-cluster environment.

[0027] In one embodiment, querying the inverted index to obtain the corresponding resource list includes:

[0028] Based on the Pod's namespace, look up the corresponding tag-policy ID mapping table;

[0029] Perform a pre-query operation, traverse all Pod tags, find the set of policy IDs that match each Pod tag in the tag-policy ID mapping table, merge all the policy ID sets found to obtain a union set, which contains all policy IDs that are associated with Pod tags;

[0030] Perform a filtering operation, iterate through each policy ID in the union set, and verify whether the complete label set of each policy ID completely matches the complete label set of the corresponding Pod;

[0031] Based on the union set after the filtering operation, the corresponding resource list is output.

[0032] In one embodiment, the space isolator is used to take effect within a specific namespace through a custom policy of the OPA Policy resource, thereby achieving namespace-level isolation; the Kubernetes tag selector is used to define different workload granularities in the OPA Policy resource.

[0033] Secondly, this application also provides a network authentication device based on ISTIO and OPA, comprising:

[0034] The configuration module is used to deploy the service agent Envoy and the OPA Agent in sidecar mode within the smallest deployment unit Pod that contains OPA;

[0035] The configuration module is also used to pre-configure ServiceEntry and ExtensionProvider resources so that Envoy can pass traffic to the OPA Agent for authentication.

[0036] The configuration module is also used to customize the content and scope of OPA authentication policies by configuring OPA Policy resources;

[0037] The synchronization module is used to synchronize the authentication policy to the corresponding Pod in a multi-cluster environment using a synchronization compensation mechanism.

[0038] The indexing module is used to build an inverted index when the system starts up or is updated periodically, mapping the label of each authentication policy to a list of resources with the corresponding label;

[0039] The indexing module is also used to query the inverted index to obtain the corresponding resource list when it is necessary to find resources with preset tags.

[0040] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0041] In the smallest deployment unit containing OPA, the Pod, deploy the service agent Envoy and the OPA Agent in sidecar mode;

[0042] Pre-configure ServiceEntry and ExtensionProvider resources to enable Envoy to pass traffic to OPAAgent for authentication;

[0043] By configuring OPA Policy resources, you can customize the content and scope of OPA authentication policies.

[0044] By utilizing a synchronization compensation mechanism, the authentication policy is synchronized to the corresponding Pod in a multi-cluster environment;

[0045] When the system is started or updated periodically, an inverted index is built to map the label of each authentication policy to a list of resources with the corresponding label.

[0046] When it is necessary to find resources with preset tags, the inverted index is queried to obtain the corresponding resource list.

[0047] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0048] In the smallest deployment unit containing OPA, the Pod, deploy the service agent Envoy and the OPA Agent in sidecar mode;

[0049] Pre-configure ServiceEntry and ExtensionProvider resources to enable Envoy to pass traffic to OPAAgent for authentication;

[0050] By configuring OPA Policy resources, you can customize the content and scope of OPA authentication policies.

[0051] By utilizing a synchronization compensation mechanism, the authentication policy is synchronized to the corresponding Pod in a multi-cluster environment;

[0052] When the system is started or updated periodically, an inverted index is built to map the label of each authentication policy to a list of resources with the corresponding label.

[0053] When it is necessary to find resources with preset tags, the inverted index is queried to obtain the corresponding resource list.

[0054] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0055] In the smallest deployment unit containing OPA, the Pod, deploy the service agent Envoy and the OPA Agent in sidecar mode;

[0056] Pre-configure ServiceEntry and ExtensionProvider resources to enable Envoy to pass traffic to OPAAgent for authentication;

[0057] By configuring OPA Policy resources, you can customize the content and scope of OPA authentication policies.

[0058] By utilizing a synchronization compensation mechanism, the authentication policy is synchronized to the corresponding Pod in a multi-cluster environment;

[0059] When the system is started or updated periodically, an inverted index is built to map the label of each authentication policy to a list of resources with the corresponding label.

[0060] When it is necessary to find resources with preset tags, the inverted index is queried to obtain the corresponding resource list.

[0061] The aforementioned network authentication methods, devices, computer equipment, computer-readable storage media, and computer program products based on ISTIO and OPA reduce the need for manual configuration and lower operational complexity by automating and optimizing the calculation, distribution, and retrieval of policies, making the network authentication process more efficient and easier to manage. Combining the capabilities of Istio and OPA provides a powerful network authentication solution that enhances the security of inter-service communication, especially in complex microservice architectures and multi-cluster environments. Through OPA Policy resources, users can customize the content and scope of authentication policies, allowing policies to flexibly adapt to different business needs and security requirements. A synchronization compensation mechanism ensures that authentication policies are correctly and consistently synchronized to the corresponding Pods in multi-cluster environments, maintaining policy execution consistency. By building an inverted index, the performance of tag-based resource retrieval is optimized, especially in large-scale environments, enabling rapid searching and matching of relevant resources and policies based on tags. Automated and optimized policy management reduces operational workload and mitigates risks caused by configuration errors, thereby reducing related operational costs. The use of the inverted index improves the speed of searching and matching policies, enabling the system to respond to authentication requests faster and enhancing the user experience. Attached Figure Description

[0062] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0063] Figure 1 This is a flowchart illustrating a network authentication method based on ISTIO and OPA in one embodiment;

[0064] Figure 2 This is a flowchart illustrating the calculation process for the OPA strategy result set matched by the pod in another embodiment.

[0065] Figure 3 This is a schematic diagram of the compensation mechanism in the embodiments of this application;

[0066] Figure 4 This is a schematic diagram of the inverted index in the embodiments of this application;

[0067] Figure 5 This is a structural block diagram of a network authentication device based on ISTIO and OPA in one embodiment;

[0068] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0069] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0070] Istio is a commonly used service mesh architecture, logically divided into a data plane and a control plane. The control plane is responsible for managing and configuring proxies to route traffic. The data plane mainly includes an extended version of the Envoy proxy. Envoy is an open-source edge and service proxy that helps decouple network issues from the underlying applications. Applications simply send messages to or receive messages from localhost without needing to know the network topology.

[0071] The combination of Istio and OPA facilitates the management of authentication logic across the entire network, and both are deployed as sidecars, requiring no intrusion into business logic. However, the community's solution requires manual configuration of the Envoy Filter, OPA startup Config Map, OPA Config Map resources, and allowing OPA ports, making it very difficult to use and unable to be changed online. In large mesh environments, multiple policies and namespaces need to be effective, which clearly cannot be achieved simply by relying on Config Maps.

[0072] This invention aims to provide a network authentication method based on ISTIO and OPA to address the shortcomings of existing technologies. Its main features are:

[0073] 1. Remove the logic of manual configuration during OPA sidecar startup and policy loading.

[0074] (1) Remove the startup dependency of Config Map.

[0075] (2) Automatically generate Service Entry and Extension Provider.

[0076] (3) Automatically configure Istio to allow OPA service ports.

[0077] 2. Provide a custom resource (CRD) OPA policy, which allows users to customize the OPA policy content, scope of application, and automatically calculate and distribute it to the corresponding pods and apply it.

[0078] 3. Provide a synchronization compensation mechanism to ensure that policy definitions can still be synchronized to the corresponding pods in the event of cluster joining / removal or program crash in a multi-cluster environment.

[0079] 4. Optimize in-memory retrieval of tags based on inverted indexes to improve performance.

[0080] In one exemplary embodiment, such as Figure 1 As shown, a network authentication method based on ISTIO and OPA is provided, including the following steps S102 to S112. Wherein:

[0081] Step S102: Deploy the service agent Envoy and the OPA Agent in the sidecar mode within the smallest deployment unit Pod that contains OPA.

[0082] Specifically, in Kubernetes, a Pod is the smallest unit of deployment and can contain one or more containers. A Pod containing OPA means that an OPA container has been deployed in a Pod. OPA acts as a policy engine for evaluating and executing policy-based decisions.

[0083] The sidecar pattern is a common microservice architecture pattern where a main container (usually the application container) and one or more auxiliary containers (sidecar containers) are deployed together in the same Pod. The sidecar containers are typically responsible for auxiliary tasks such as log collection, monitoring, and network proxying.

[0084] Envoy is a high-performance service broker used to handle network traffic between services, including traffic forwarding, routing, and health checks. In service mesh architectures, Envoy is often used as a core component of the data plane. In this Pod, Envoy is deployed as a sidecar container for OPA. This allows Envoy to integrate tightly with OPA, leveraging OPA's policy decision-making capabilities to manage traffic. This deployment method allows Envoy to delegate traffic decision-making authority to OPA, enabling OPA-based traffic control and authentication. Simultaneously, this means that Envoy's configuration (such as ServiceEntry and ExtensionProvider) can be automatically generated, and OPA's business ports can be automatically configured to allow communication between Envoy and OPA. This allows for flexible deployment and management of the OPA-Envoy integration in a Kubernetes environment, enabling the use of OPA's policy decision-making capabilities to manage and control network traffic between microservices.

[0085] In an exemplary embodiment, during the deployment of the service agent Envoy and the OPA Agent in the sidecar mode within the smallest deployment unit Pod containing OPA, the Config Map resource is removed via the OPA sidecar, and the OPA listening address and policy evaluation path are configured via container startup parameters.

[0086] Specifically, in Kubernetes, a Config Map is a resource used to store configuration data that can be used by containers within a Pod. Removing the dependency on the Config Map during OPA sidecar startup and policy loading means that OPA configuration parameters and policies are no longer passed through the Config Map, thus simplifying configuration management.

[0087] Among them, container startup parameters are parameters passed to the application or service in the container when the container starts. These parameters can be used to configure the application behavior inside the container.

[0088] In this design, the OPA listening address and policy evaluation path are no longer configured through a Config Map, but are instead passed directly as container startup parameters. This allows the OPA container to be configured directly at startup without relying on external Config Map resources.

[0089] The configuration of the OPA container can be achieved in the following ways:

[0090] json

[0091] opa_container = {

[0092] image: "xxxxx",

[0093] "name": "opa-istio",

[0094] "args": [

[0095] "run",

[0096] "--server",

[0097] --addr=0.0.0.0:18181",

[0098] "--set=plugins.envoy_ext_authz_grpc.addr=:19191",

[0099] "--set=plugins.envoy_ext_authz_grpc.path=istio / authz / allow",

[0100] "--set=decision_logs.console=true",

[0101] "--diagnostic-addr=0.0.0.0:18282",

[0102] ],

[0103] "volumeMounts": [],

[0104] }

[0105] In this example, the startup parameters for the OPA container include:

[0106] --addr=0.0.0.0:18181: Sets the listening address and port for OPA.

[0107] --set=plugins.envoy_ext_authz_grpc.addr=:19191: Sets the address and port for Envoy to communicate with OPA.

[0108] --set=plugins.envoy_ext_authz_grpc.path=istio / authz / allow: Sets the policy evaluation path.

[0109] In this embodiment, by removing the Config Map resource through the OPA sidecar and directly configuring the OPA listening address and policy evaluation path through container startup parameters, it helps to reduce configuration complexity and improve the system's flexibility and maintainability.

[0110] Step S104: Configure ServiceEntry and ExtensionProvider resources to enable Envoy to pass traffic to the OPA Agent for authentication.

[0111] Specifically, a Service Entry is a custom resource in Istio that allows the Istio service mesh to understand how to access external services within the mesh. In this case, it defines how to access the OPA service. By defining a Service Entry, the hostname and port of the OPA service can be specified, allowing the Envoy proxy in the Istio mesh to route traffic to the OPA. This configuration enables Envoy to recognize and communicate with the OPA service.

[0112] Extension Provider resources are used to configure Envoy to perform specific operations, such as authentication decisions, using external services (like OPA). By defining an Extension Provider, you can specify the service name, port, and authentication behavior that Envoy uses to communicate with OPA. This includes setting up Envoy to communicate with OPA via gRPC and defining how authentication requests and responses are handled.

[0113] The OPA service ports are the network ports that OPA uses to receive and respond to Envoy authentication queries. For Envoy to delegate authentication traffic decision-making authority to the OPA sidecar, it's necessary to ensure that the OPA service ports are open to Envoy. This typically involves allowing these ports in Istio's network policies to prevent any network access control rules from blocking communication between Envoy and OPA.

[0114] With the above configuration, Envoy is set to delegate authentication decisions to OPA when processing inbound traffic. Envoy sends authentication requests to OPA and decides whether to allow the request based on OPA's response (allow or deny). This integration allows for flexible and dynamic policy-based control of inter-service communication, providing a fine-grained access control mechanism.

[0115] In one exemplary embodiment, ServiceEntry and ExtensionProvider resources are pre-configured to enable Envoy to pass traffic to the OPA Agent for authentication, including:

[0116] Services are defined through Service Entry resources, specifying the hostname and port of the service entry point so that Istio can route traffic to OPA;

[0117] Enable the OPA service port and configure Envoy through the Extension Provider resource so that Envoy can transfer the decision authority for authentication traffic to the OPA sidecar.

[0118] Configure access control policies in Istio through the Authorization Policy resource, specify the services that need to be checked for OPA authorization, and reference the OPA services defined in the Extension Provider resource.

[0119] Specifically, services are defined through Service Entry resources: Service Entry resources are used to define access rules for external services within the Istio service mesh. In this context, it is used to specify how to access the OPA service. By defining a Service Entry, the hostname and port of the OPA service can be specified, allowing Istio to route traffic to OPA. This way, when Envoy needs to make authentication decisions, it can send requests to OPA.

[0120] Configuring Envoy via Extension Provider Resources: Extension Provider resources are used to configure Envoy to perform specific operations using external services (such as OPA), such as authentication decisions. Through the Extension Provider, Envoy is configured to grant decision-making authority over authentication traffic. This involves specifying the service name, port, and authentication behavior for communication with OPA. For Envoy to communicate with OPA, the OPA's service ports need to be opened. This typically involves allowing these ports in Istio's network policy to prevent any network access control rules from blocking communication between Envoy and OPA.

[0121] Configure access control policies through the Authorization Policy resource: The Authorization Policy resource is used to configure access control policies in Istio, specifying which services require OPA authorization checks. By referencing the OPA service defined in the Extension Provider resource within the Authorization Policy, you can ensure that Envoy sends authentication requests to the correct OPA service instance.

[0122] The following are specific examples:

[0123] Service Entry Example:

[0124] yaml

[0125] apiVersion: networking.istio.io / v1beta1

[0126] kind: ServiceEntry

[0127] metadata:

[0128] name: opa-service-entry

[0129] spec:

[0130] hosts:

[0131] - "opa.opa-istio.internal

[0132] ports:

[0133] - number: 19191

[0134] name: grpc

[0135] protocol: GRPC

[0136] location: MESH_INTERNAL

[0137] resolution: STATIC

[0138] endpoints:

[0139] - address: 127.0.0.1

[0140] This ServiceEntry defines how to access the OPA service and route traffic to OPA. This YAML file defines a ServiceEntry named "ext-authz". It's used to configure service ingress rules in the Istio service mesh. It specifies the hostname and port of a service ingress, and how to route traffic to a specific endpoint. This configuration allows Istio to direct traffic to a service named "ext-authz.opa-istio.internal" with port number 19191 specified.

[0141] Extension Provider Example:

[0142] yaml

[0143] apiVersion: networking.istio.io / v1beta1

[0144] kind: ExtensionProvider

[0145] metadata:

[0146] name: opa-authz

[0147] spec:

[0148] envoyExtAuthzGrpc:

[0149] service: "opa.opa-istio.internal"

[0150] port: "19191"

[0151] failOpen: true

[0152] includeRequestBodyInCheck:

[0153] maxRequestBytes: 8192

[0154] allowPartialMessage: true

[0155] This ExtensionProvider configures Envoy to communicate with OPA, allowing Envoy to make decisions regarding authentication traffic permissions. This YAML file defines an extension provider named "opa-ext-authz-grpc" used to configure Envoy's external authorization and gRPC authentication. It specifies the service name and port for communicating with the external authentication service and configures authentication behavior options, such as whether to allow parts of the request body to be included in the authentication check. The corresponding `envoyExtAuthzGrpc.service` corresponds to the `spec.hosts` property of the aforementioned ServiceEntry.

[0156] Example of Authorization Policy:

[0157] yaml

[0158] apiVersion: security.istio.io / v1beta1

[0159] kind: AuthorizationPolicy

[0160] metadata:

[0161] name: opa-authz-policy

[0162] spec:

[0163] selector:

[0164] matchLabels:

[0165] app: your-app

[0166] action: CUSTOM

[0167] provider:

[0168] name: opa-authz

[0169] This `AuthorizationPolicy` configures the access control policy in Istio and references the OPA service. This YAML file defines an `AuthorizationPolicy` named "ext-authz" used to configure the access control policy in Istio. It specifies the application tag selector to which the authorization policy applies, as well as the custom authorization provider name and authorization rules used. Here, it applies the authorization policy to the application with the tag "app:productpage", triggered by a request path matching " / *". `provider.name` corresponds to `extensionProviders.name` of the aforementioned external authorization policy.

[0170] In summary, by configuring Istio to generate Service Entry and Extension Provider resources and opening the OPA business port, Envoy and OPA can be integrated, enabling Envoy to make decisions on authentication traffic permissions. This integration provides a flexible and scalable way to implement fine-grained access control and authentication policies.

[0171] Step S106: Configure the OPA Policy resource to customize the content and scope of the OPA authentication policy.

[0172] Specifically, an OPA Policy is a Kubernetes Custom Resource Definition (CRD) that allows users to define and manage OPA policies declaratively within a Kubernetes cluster. Within the OPA Policy resource, users can write specific policy logic, typically expressed using OPA's Rego language. Rego is a declarative logic language specifically designed for writing and querying policies.

[0173] Users define the specific details of authentication policies in OPA Policy, such as which users can access which resources, or under what conditions requests are allowed or denied. These policies can be dynamically loaded into OPA, meaning they can be updated without restarting the service, achieving hot updates. The scope of the defined policies includes namespace isolation and tag selectors.

[0174] OPA Policy resources allow users to automatically manage and distribute authentication policies without manually modifying configuration files or redeploying services. In multi-cluster environments, changes to OPA Policy resources can be synchronized to all relevant clusters, ensuring consistency of authentication policies.

[0175] In an exemplary embodiment, the OPA Policy resource includes an OPA Policy Spec structure; by configuring the OPA Policy resource, the content and scope of the OPA authentication policy can be customized, including:

[0176] By configuring the OPA Policy Spec structure, the workload selector and authentication policy fields are determined. The workload selector includes a namespace isolator and a Kubernetes label selector, both of which are used to specify the scope of the authentication policy. The authentication policy field includes the policy content written in Rego syntax.

[0177] In one exemplary embodiment, a space isolator is used to implement namespace-level isolation by taking effect within a specific namespace through a custom policy of the OPA Policy resource; a Kubernetes label selector is used to define different workload granularities in the OPA Policy resource.

[0178] Specifically, the OPA Policy Spec structure is the core of the OPA Policy resource, defining the specific content and scope of the policy.

[0179] The Workload Selector includes: Namespace Isolator: Through the namespace isolator, OPA Policy can specify that a policy only takes effect within a specific Kubernetes namespace, thereby achieving namespace-level isolation. Kubernetes Tag Selector: Using the Kubernetes tag selector, OPA Policy can further refine the scope of the policy, making the policy only applicable to resources with specific tags (such as Pods).

[0180] The authentication policy field contains the policy content written in the Rego language. Rego is a declarative logic language specifically designed for writing and querying policies. In this field, users can define specific authentication rules and logic, such as which users can access which resources, or under what conditions requests are allowed or denied.

[0181] Within the OPA Policy Spec structure, users configure workload selectors to specify which resources should be affected by the policy. Users write REGO code in the authentication policy field to define the specific authentication logic.

[0182] Below is a sample configuration for an OPA Policy resource:

[0183] yaml

[0184] apiVersion: policy.example.com / v1beta1

[0185] kind: OpaPolicy

[0186] metadata:

[0187] name: example-policy

[0188] namespace: default

[0189] spec:

[0190] policy: |-

[0191] package istio.authz

[0192] import input.attributes.request.http as http_request

[0193] default allow := false

[0194] allow {

[0195] roles_for_user[r]

[0196] required_roles[r]

[0197] }

[0198] roles_for_user[r] {

[0199] r := user_roles[user_name][_]

[0200] }

[0201] required_roles[r] {

[0202] perm := role_perms[r][_]

[0203] perm.method = http_request.method

[0204] perm.path = http_request.path

[0205] }

[0206] user_name = parsed {

[0207] [_, encoded] := split(http_request.headers.authorization, " ")

[0208] [parsed, _] := split(base64url.decode(encoded), ":")

[0209] }

[0210] user_roles = {

[0211] "guest1": ["guest"],

[0212] "admin1": ["admin"]

[0213] }

[0214] role_perms = {

[0215] "guest": [

[0216] {"method": "GET", "path": " / productpage"},

[0217] ],

[0218] "admin": [

[0219] {"method": "GET", "path": " / productpage"},

[0220] {"method": "GET", "path": " / api / v1 / products"},

[0221] ],

[0222] }

[0223] workloadSelector:

[0224] matchLabels:

[0225] app: my-app

[0226] In this example: `workloadSelector` specifies that the policy applies to resources with the tag `app:my-app`. The `policy` field contains the policy content written in Rego syntax, defining the access control logic based on user roles. In this example, the policy means: if logged in as the `guest` group, only ` / productpage` can be accessed; if logged in as the `admin` group, both ` / productpage` and ` / api / v1 / products` can be accessed, where `guest1` belongs to the `guest` group and `admin1` belongs to the `admin` group.

[0227] In this embodiment, by configuring OPA Policy resources and OPA Policy Spec structures, users can customize the content and scope of OPA authentication policies, thereby achieving fine-grained access control and authentication management. This mechanism provides a flexible and scalable way to manage authentication policies in a microservice architecture.

[0228] Step S108: Using the synchronization compensation mechanism, the authentication policy is synchronized to the corresponding Pod in a multi-cluster environment.

[0229] Specifically, in a multi-cluster environment, different clusters may be distributed across different geographical locations or data centers. To ensure that Pods in all clusters follow the same authentication policy, when the policy is updated, the changes should be quickly and accurately synchronized to all clusters. In the event of network partitions, cluster failures, or other anomalies, the synchronization and consistency of the policy should be maintained. A synchronization compensation mechanism should be used to synchronize the authentication policy to the corresponding Pods in a multi-cluster environment.

[0230] Among them, the synchronization compensation mechanism is a technical means to ensure the consistency and correctness of the strategy in a multi-cluster environment. It includes the following aspects:

[0231] 1. Listening and event dispatching:

[0232] OPA Controller Listener: A dedicated OPA controller (Kubernetes controller) listens for add, delete, and modify events of OPA Policy resources.

[0233] Event push: When changes to OPA Policy resources are detected, the OPA controller pushes these changes as events to the affected Pods.

[0234] 2. Initial synchronization and filtering:

[0235] Pod startup synchronization: When a Pod starts, the OPA controller synchronizes all relevant policies to the Pod based on the Pod's tag and namespace.

[0236] Filtering by Tag: The OPA controller filters out a set of policies that match the Pod based on the Pod's tags, ensuring that only the relevant policies are applied to the Pod.

[0237] 3. Recalculate periodically:

[0238] Scheduled tasks: The OPA controller periodically executes a recalculation task to check the policy status of all Pods and ensure that they are consistent with the latest OPA Policy resources.

[0239] Exception handling: In the event of an exception (such as an OPA controller restart, network problems, etc.), recalculating the task can help restore data consistency and ensure that the policy is correctly synchronized to all Pods.

[0240] In an exemplary embodiment, a synchronization compensation mechanism is used to synchronize the authentication policy to the corresponding Pod in a multi-cluster environment, including:

[0241] The OPA controller listens for add, delete, and modify events of OPA Policy resources and synchronizes any abnormal events in these events to the affected Pods.

[0242] When a Pod is started, an authentication policy set related to the corresponding Pod is generated by the OPA controller based on the Pod tag, and the authentication policy set is filtered.

[0243] In the event of an OPA controller restart, network problems, or other abnormal situations, the authentication policy status is updated periodically through the OPA controller so that the authentication policy is synchronized to the corresponding Pod in a multi-cluster environment.

[0244] Specifically, the OPA controller is a dedicated controller responsible for managing OPA Policy resources. It listens for any changes to these resources, including creation, update, and deletion events. When the OPA controller detects changes to OPA Policy resources, it synchronizes these changes (especially anomalies) to the affected Pods. This ensures that the policies in the Pods are always up-to-date and can respond promptly to policy changes.

[0245] When a Pod starts, the OPA controller determines which authentication policies apply to that Pod based on its tags. This is done by matching the Pod tags with the workload selectors defined in the OPA Policy. The OPA controller not only generates a set of policies associated with each Pod, but also filters these policies to ensure that only policies matching the Pod tags and namespaces are applied to the Pod.

[0246] In cases of OPA controller restarts or network issues, policy synchronization may be interrupted. To address this, the OPA controller periodically updates the state of the authentication policies. This periodic update mechanism ensures that even in a multi-cluster environment, authentication policies are correctly and consistently synchronized to all corresponding Pods, maintaining policy consistency and correctness.

[0247] The synchronization compensation mechanism ensures that all Pods in a multi-cluster environment receive the latest authentication policies in a timely manner, regardless of which cluster they reside in. Through regular updates and exception handling, the system remains stable in the face of network problems or controller failures, reducing the risk of policy synchronization failures. Through listening and synchronization mechanisms, the system can quickly respond to policy changes, improving the responsiveness to policy changes and overall performance.

[0248] In this embodiment, the synchronization compensation mechanism is a key technology to ensure that authentication policies can be synchronized to each relevant Pod in a timely and accurate manner in a multi-cluster environment. This mechanism achieves automated management and synchronization of policies by monitoring changes in OPA Policy resources, synchronizing policies based on Pod tags, and periodically updating the policy state in abnormal situations.

[0249] Step S110: When the system is started or updated periodically, an inverted index is constructed to map the label of each authentication policy to a resource list with the corresponding label.

[0250] Specifically, an inverted index is an index data structure commonly used in search engines that maps words in a document to a list of documents containing those words. In the context of authentication policies, an inverted index maps policy tags to resources (such as Pods) that have those tags. By using an inverted index, relevant policies can be quickly found based on tags, rather than traversing all policies, thus improving retrieval efficiency. In large-scale environments, inverted indexes can significantly reduce the time required to find resources with specific tags, improving system response speed.

[0251] The system first collects tags for all authentication policies. For each tag, the system finds all resources with that tag and associates these resources with the tag. The system builds an index where each tag points to a list of resources, each with a corresponding tag. An inverted index is built at system startup to ensure that an up-to-date index is available from the beginning. The system periodically rebuilds or updates the inverted index to reflect any changes to resources and policies. Whenever a new resource is added or a tag is modified, the system can update the inverted index to reflect these changes.

[0252] It's important to note that after obtaining the results from the inverted index, a forward index is also needed to filter the pre-query results. This involves iterating through all tags in `union_policy_ids` and comparing each tag to see if the complete set of `workloadSelector` tags for the policy details is fully contained within the `pod` tags.

[0253] Step S112: When it is necessary to find resources with preset tags, query the inverted index to obtain the corresponding resource list.

[0254] Specifically, first, determine the preset tags to be queried. These tags may be defined by a strategy or preset according to business logic. Using the preset tags as keys, query the inverted index to find a list of all resources with these tags. The inverted index will return a list of resources associated with the query tags. This list contains all matching resources, all of which have the tags specified in the query. In authentication strategies, the inverted index can be used to quickly find resources for which a specific strategy needs to be applied.

[0255] The aforementioned network authentication methods based on ISTIO and OPA reduce the need for manual configuration and lower operational complexity by automating and optimizing policy calculation, distribution, and retrieval, making the network authentication process more efficient and easier to manage. Combining the capabilities of Istio and OPA provides a powerful network authentication solution that enhances the security of inter-service communication, especially in complex microservice architectures and multi-cluster environments. Through OPA Policy resources, users can customize the content and scope of authentication policies, allowing policies to flexibly adapt to different business needs and security requirements. A synchronization compensation mechanism ensures that authentication policies are correctly and consistently synchronized to the corresponding Pods in multi-cluster environments, maintaining policy execution consistency. By building an inverted index, the performance of tag-based resource retrieval is optimized, especially in large-scale environments, enabling rapid searching and matching of relevant resources and policies based on tags. Automated and optimized policy management reduces operational workload and mitigates risks caused by configuration errors, thereby reducing related operational costs. The use of the inverted index improves the speed of policy searching and matching, enabling the system to respond to authentication requests faster and enhancing the user experience.

[0256] In one exemplary embodiment, the inverted index is queried to obtain the corresponding resource list, such as... Figure 2 As shown, it includes:

[0257] Step S202: Based on the Pod's namespace, find the corresponding tag-policy ID mapping table;

[0258] Step S204: Perform a pre-query operation, traverse all Pod tags, find the set of policy IDs that match each Pod tag in the tag-policy ID mapping table, merge all the policy ID sets found to obtain a union set, and the union set contains all policy IDs that are associated with the Pod tag;

[0259] Step S206: Perform a filtering operation, traverse each policy ID in the union set, and verify whether the complete label set of each policy ID completely matches the complete label set of the corresponding Pod;

[0260] Step S208: Output the corresponding resource list based on the union set after the filtering operation.

[0261] Specifically, such as Figure 3 As shown, firstly, the system will look up the mapping table from the corresponding label to the policy ID in the pre-built inverted index based on the namespace to which the Pod belongs (i.e., Figure 4 The namespace_map shown here contains the labels and corresponding policy IDs for all policies within that namespace.

[0262] Next, a pre-query operation is performed, where the system iterates through all tags on the Pod. For each tag, the system searches the tag-to-policy-ID mapping table for a set of policy IDs that match that tag. All the found policy ID sets are merged to form a union set `union_policy_ids`, which contains all policy IDs associated with the Pod tag.

[0263] Next, a filtering operation is performed. The system iterates through each policy ID in `union_policy_ids` and verifies whether the complete tag set corresponding to each policy ID completely matches the complete tag set of the Pod. Only when the policy's tag set is completely contained within the Pod's tag set is the policy considered a match for the Pod.

[0264] Finally, based on the results of the filtering operation, the system outputs the final resource list, which is the set of policies that exactly match the Pod tags.

[0265] In this embodiment, the inverted index enables the system to quickly find and match relevant policies based on tags, improving retrieval efficiency. The filtering operation ensures that only policies that exactly match Pod tags are selected, improving the accuracy of policy application. The process of querying the inverted index to obtain the corresponding resource list is an efficient policy retrieval and matching mechanism, allowing the system to quickly and accurately retrieve and apply relevant authentication policies based on Pod tags.

[0266] In a specific embodiment, such as Figure 3As shown, opa-controller still needs to perform startup alignment and periodic recalculation to ensure that there is a chance to align the data in abnormal situations.

[0267] Scheduled calculations require fetching all pods and policies, comparing them with the policies already fetched by each pod, and finally controlling the distribution of the difference set. Excess policies are deleted, while changed or missing policies are put.

[0268] Since we need to find the scope of pods based on policy labels, and also find the set of policies based on pod labels, finding pods by policy is obviously easier. However, finding policies by pods requires introducing an inverted index. Considering that some policies have no labels, such as... Figure 4 As shown, this applies to all pods under the namespace, maintaining a namespace map (denoted as map1). In addition, each policy label is used to create a separate map of label->policy_id (denoted as map2). The policy_id to policySpec map can be generated using Kubernetes caching, denoted as policy_id_Map.

[0269] After the OPA controller starts, it iterates through all policies, retrieves the corresponding labels, and builds an index.

[0270] Add a policy: Iterate through the corresponding labels and add the policy_id to the policy_id_set of the corresponding label.

[0271] Delete policy: Iterate through all labels, query and delete the key (i.e., label) in map2.

[0272] Update the policy by iterating through all labels, querying and updating map2.

[0273] The steps involved in matching a pod with a specific policy are as follows:

[0274] 1. Query namespace: First, in map1, query map2 (label-policy_id_set) under the specific namespace based on the namespace.

[0275] 2. Pre-query: Iterate through the labels of each label, query map2 to get the policy_id result set policy_id_set for each label, and take the union of the policy_id_sets of multiple labels union_policy_ids. The final policy result set must be in this union.

[0276] 3. Because policies may have other filtering conditions, the above unions are all results obtained by inverting individual tags. A forward sort is also needed to filter the pre-query results. That is, iterate through all tags in union_policy_ids and compare each tag to see if the complete set of workloadSelector tags for policy details is fully contained within the pod tags.

[0277] 4. Return the final result set.

[0278] Example as follows:

[0279] Assuming pod1 has labels L1, L2, and L3, and there are currently the following in the same namespace:

[0280] Policy 1: No label;

[0281] Policy 2: L1;

[0282] Policy 3: L3, L4;

[0283] Policy 4: L4;

[0284] The constructed inverted index is as follows:

[0285] L1->Policy2;

[0286] L3->Policy3;

[0287] L4->Policy3,Policy4;

[0288] The query process is as follows:

[0289] Pod1 finds Policy{1,2,3,4} based on the namespace;

[0290] Pre-query: Policy1 has no label and meets the condition. L1 reverse query finds Policy2. L2 has no results. L3 reverse query finds Policy3. union_policy_ids is Policy{1,2,3}.

[0291] In the forward sorting query, policy3 is excluded because it contains L4 and does not completely belong to Pod1, leaving only Policy{1,2} in the result set;

[0292] Returns the final result set Policy{1,2}.

[0293] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0294] Based on the same inventive concept, this application also provides an ISTIO and OPA-based network authentication device for implementing the ISTIO and OPA-based network authentication method described above. The solution provided by this device is similar to the implementation described in the above method. Therefore, the specific limitations in one or more ISTIO and OPA-based network authentication device embodiments provided below can be found in the limitations of the ISTIO and OPA-based network authentication method described above, and will not be repeated here.

[0295] In one exemplary embodiment, such as Figure 5 As shown, a network authentication device based on ISTIO and OPA is provided, including: a configuration module 502, used to deploy the service agent Envoy and the OPA Agent in the sidecar mode in the smallest deployment unit Pod containing OPA;

[0296] Configuration module 502 is also used to pre-configure ServiceEntry and ExtensionProvider resources so that Envoy can pass traffic to the OPA Agent for authentication;

[0297] Configuration module 502 is also used to customize the content and scope of OPA authentication policies by configuring OPA Policy resources;

[0298] Synchronization module 504 is used to synchronize the authentication policy to the corresponding Pod in a multi-cluster environment using a synchronization compensation mechanism.

[0299] Index module 506 is used to build an inverted index when the system starts up or is periodically updated, mapping the label of each authentication policy to a list of resources with the corresponding label;

[0300] The index module 506 is also used to query the inverted index and obtain the corresponding resource list when it is necessary to find resources with preset tags.

[0301] In one embodiment, the configuration module 502 is further configured to remove Config Map resources through the OPA sidecar during the process of deploying the service agent Envoy and the OPA Agent in the smallest deployment unit Pod containing OPA in sidecar mode, and to configure the listening address and policy evaluation path of OPA through container startup parameters.

[0302] In an exemplary embodiment, the configuration module 502 is specifically used to define services through the Service Entry resource, specify the hostname and port of the service entry point so that Istio routes traffic to OPA; open the service port of OPA, configure Envoy through the Extension Provider resource so that Envoy transfers the decision authority for authentication traffic to the sidecar of OPA; configure the access control policy in Istio through the Authorization Policy resource, specify the services that need to be checked for OPA authorization, and reference the OPA service defined in the Extension Provider resource.

[0303] In an exemplary embodiment, the OPA Policy resource includes an OPA Policy Spec structure; the configuration module 502 is specifically used to determine the workload selector and authentication policy field by configuring the OPA Policy Spec structure; wherein, the workload selector includes a namespace isolator and a Kubernetes label selector, both of which are used to specify the scope of the authentication policy; the authentication policy field includes policy content written using Rego syntax.

[0304] In an exemplary embodiment, the synchronization module 504 is specifically used to listen for add, delete, and modify events of OPAPolicy resources through the OPA controller, and synchronize abnormal events in the add, delete, and modify events to the affected Pods; when a Pod is started, the OPA controller generates an authentication policy set related to the corresponding Pod based on the Pod tag, and filters the authentication policy set; when the OPA controller restarts, a network problem occurs, or other abnormal situations occur, the OPA controller periodically updates the status of the authentication policy so that the authentication policy is synchronized to the corresponding Pod in a multi-cluster environment.

[0305] In an exemplary embodiment, the indexing module 506 is specifically used to: search for the corresponding tag-policy ID mapping table based on the Pod's namespace; perform a pre-query operation, traversing all Pod tags, searching for a set of policy IDs matching each Pod tag in the tag-policy ID mapping table, merging all found policy ID sets to obtain a union set, which contains all policy IDs associated with Pod tags; perform a filtering operation, traversing each policy ID in the union set, verifying whether the complete tag set of each policy ID completely matches the complete tag set of the corresponding Pod; and output the corresponding resource list based on the union set after the filtering operation.

[0306] In one exemplary embodiment, a space isolator is used to implement namespace-level isolation by taking effect within a specific namespace through a custom policy of the OPA Policy resource; a Kubernetes label selector is used to define different workload granularities in the OPA Policy resource.

[0307] The modules in the aforementioned network authentication device based on ISTIO and OPA can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0308] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements a network authentication method based on ISTIO and OPA.

[0309] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0310] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, performs the method described above.

[0311] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the method described above.

[0312] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0313] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0314] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0315] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A network authentication method based on ISTIO and OPA, characterized in that, The method includes: In the smallest deployment unit containing OPA, the Pod, deploy the service agent Envoy and the OPA Agent in sidecar mode; Configure ServiceEntry and ExtensionProvider resources to enable Envoy to pass traffic to the OPA Agent for authentication; By configuring OPA Policy resources, you can customize the content and scope of OPA authentication policies. The OPA Policy resource includes an OPA Policy Spec structure. By configuring the OPA Policy Spec structure, the workload selector and authentication policy fields are determined. The workload selector includes a namespace isolator and a Kubernetes label selector. Both the namespace isolator and the Kubernetes label selector are used to specify the scope of the authentication policy. The authentication policy fields include policy content written using Rego syntax. By utilizing a synchronization compensation mechanism, the authentication policy is synchronized to the corresponding Pod in a multi-cluster environment; The synchronization compensation mechanism includes: monitoring OPA Policy resource addition, deletion, and modification events through the OPA controller, and synchronizing abnormal events in these events to the affected Pods; when a Pod is running, generating an authentication policy set related to the corresponding Pod through the OPA controller based on the Pod tag, and filtering the authentication policy set; and periodically updating the status of the authentication policies through the OPA controller in the event of an OPA controller restart, network problems, or other abnormal situations, so that the authentication policies are synchronized to the corresponding Pods in a multi-cluster environment. When the system is started or periodically updated, an inverted index is constructed to map the label of each authentication policy to a resource list with the corresponding label; wherein, the construction of the inverted index includes: establishing a label-policy ID mapping table for each namespace; When it is necessary to find resources with preset tags, the inverted index is queried to obtain the corresponding resource list. The querying of the inverted index includes: finding the corresponding tag-policy ID mapping table based on the Pod's namespace; performing a pre-query operation, traversing all Pod tags, finding the set of policy IDs matching each Pod tag in the tag-policy ID mapping table, merging all found policy ID sets to obtain a union set, which contains all policy IDs associated with Pod tags; performing a filtering operation, traversing each policy ID in the union set, verifying whether the complete tag set of each policy ID completely matches the complete tag set of the corresponding Pod; and outputting the corresponding resource list based on the union set after the filtering operation.

2. The method according to claim 1, characterized in that, The method further includes: In the smallest deployment unit Pod containing OPA, during the deployment of the service agent Envoy and OPA Agent in sidecar mode, the Config Map resource is removed through the OPA sidecar, and the listening address and policy evaluation path of OPA are configured through container startup parameters.

3. The method according to claim 1, characterized in that, The pre-configured ServiceEntry and ExtensionProvider resources enable Envoy to pass traffic to the OPA Agent for authentication, including: Services are defined through Service Entry resources, specifying the hostname and port of the service entry point so that Istio can route traffic to OPA; Enable the OPA service port and configure Envoy through the Extension Provider resource so that Envoy can transfer the decision authority for authentication traffic to the OPA sidecar. Configure access control policies in Istio through the Authorization Policy resource, specify the services that need to be checked for OPA authorization, and reference the OPA services defined in the Extension Provider resource.

4. The method according to claim 1, characterized in that, The space isolator is used to implement namespace-level isolation within a specific namespace through custom policies of the OPA Policy resource; the Kubernetes label selector is used to define different workload granularities in the OPA Policy resource.

5. A network authentication device based on ISTIO and OPA, characterized in that, The apparatus, used in any one of claims 1-4, comprises: The configuration module is used to deploy the service agent Envoy and the OPA Agent in sidecar mode within the smallest deployment unit Pod that contains OPA; The configuration module is also used to pre-configure ServiceEntry and ExtensionProvider resources so that Envoy can pass traffic to the OPA Agent for authentication. The configuration module is also used to customize the content and scope of OPA authentication policies by configuring OPA Policy resources; The synchronization module is used to synchronize the authentication policy to the corresponding Pod in a multi-cluster environment using a synchronization compensation mechanism. The indexing module is used to build an inverted index when the system starts up or is updated periodically, mapping the label of each authentication policy to a list of resources with the corresponding label; The indexing module is also used to query the inverted index to obtain the corresponding resource list when it is necessary to find resources with preset tags.

6. A computer 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 the method according to any one of claims 1 to 4.

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

Images