Network authentication method and device based on ISTIO and OPA and computer equipment

Abstract

The invention 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 sidecar mode in a minimum deployment unit Pod containing the OPA; the method comprises the following steps of: configuring an Istio, generating a Service Entry resource and an Extension Provider resource, and opening a service port of an OPA (Open Power Area); the method comprises the following steps of: customizing the content and the effective range of an authentication strategy of the OPA by configuring an OPA Policy resource; synchronizing the authentication strategy to a corresponding Pod in a multi-cluster environment by using a synchronous compensation mechanism; constructing a reverse index, and mapping the label of each authentication strategy to a resource list with the corresponding label; and under the condition that the resource with the preset tag needs to be searched, querying the reverse index to obtain a corresponding resource list. By adopting the method, the network authentication process is more efficient, flexible and easy to manage through automatic management and calculation, distribution and retrieval of the optimization strategy.

Description

Technical Field

[0001] The present application relates to the field of microservice technology, and in particular to a network authentication method, apparatus, computer equipment, computer-readable storage medium, and computer program product based on ISTIO and OPA. Background Art

[0002] In modern cloud computing and microservice architecture, secure and effective management of inter-service communication has become an important issue. With the rapid development of cloud native technology, the Service Mesh architecture has emerged, providing an infrastructure layer dedicated to handling inter-service communication. The main responsibility of the service mesh is to achieve reliable request transmission under complex service topology structures, and to sink service governance capabilities so that business logic can focus more on core functions.

[0003] Istio is one of the more popular service mesh implementations. It provides a unified way to manage, monitor and protect communications between microservices. Istio is logically divided into a data plane and a control plane. The data plane is mainly composed of Envoy proxies, which are responsible for handling the actual traffic between services, including traffic forwarding, routing, health checks, etc. The control plane is responsible for managing and configuring proxies to route traffic, including the configuration of authentication policies, authorization policies, and secure naming information. Istio's security components include certificate authorities (CAs) for key and certificate management, as well as Sidecar and edge proxies as policy enforcement points (PEPs) to protect the security of communications between clients and servers. In addition, Envoy proxy extensions are used to manage telemetry and auditing.

[0004] OPA is a lightweight, general-purpose policy engine that can coexist with services, transferring policy decisions to OPA by executing queries. Services provide structured data (such as JSON) as input, and OPA evaluates these policies and data to generate query results. Policies are written in a high-level declarative language and can be dynamically loaded into OPA remotely through an API or a local file system. The way OPA operates separates policy decisions from policy execution, allowing software to query OPA and provide structured data as input when it needs to make policy decisions. This flexibility and dynamism makes OPA an ideal tool for managing complex policy decisions.

[0005] Although Istio and OPA each provide powerful features, there are some challenges in using them together in practical applications. The combination solutions provided by the community usually require manual configuration of EnvoyFilter, OPA startup parameters and authentication policies, which not only increases the usage threshold, but also makes it difficult to adapt to the needs of multiple policies and multiple namespaces in large service meshes.

[0006] Therefore, there is an urgent need for a network authentication method, apparatus, computer device, 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 management and optimizing the calculation, distribution and retrieval of policies. Summary of the invention

[0007] Based on this, it is necessary to provide a network authentication method, device, computer equipment, computer-readable storage medium and computer program product based on ISTIO and OPA, which can make the network authentication process more efficient, flexible and easy to manage through automated management and optimization of strategy calculation, distribution and retrieval, in order to address the above technical problems.

[0008] In a first aspect, the present application provides a network authentication method based on ISTIO and OPA, including:

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

[0010] Preset ServiceEntry resources and ExtensionProvider resources to enable Envoy to transparently transmit traffic to OPAAgent for authentication;

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

[0012] Use the synchronization compensation mechanism to synchronize the authentication policy to the corresponding Pod in a multi-cluster environment;

[0013] When starting the system or updating the system regularly, build an inverted index 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 a corresponding resource list.

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

[0016] In the process of deploying the service proxy Envoy and OPA Agent in the sidecar mode in the smallest deployment unit Pod that includes OPA, the Config Map resources are removed through the OPA sidecar, and the listening address and policy evaluation path of OPA are configured through the container startup parameters.

[0017] In one embodiment, the pre-setting of ServiceEntry resources and ExtensionProvider resources to enable Envoy to transparently transmit traffic to OPA Agent for authentication includes:

[0018] Define the service through the Service Entry resource, specify the host name and port of the service entry so that Istio can route traffic to OPA;

[0019] Open the OPA service port and configure Envoy through the Extension Provider resource so that Envoy transfers the decision-making authority of authentication traffic to the OPA sidecar;

[0020] Configure the access control policy in Istio through the Authorization Policy resource, specify the services that require OPA authorization check, and reference the OPA service defined in the Extension Provider resource.

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

[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, and both the namespace isolator and the Kubernetes label selector are used to specify the effective scope of the authentication policy; the authentication policy field includes the policy content written in Rego syntax.

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

[0024] The OPA controller monitors the addition, deletion, and modification events of OPA Policy resources, and synchronizes abnormal events in the addition, deletion, and modification events to the affected Pods.

[0025] When the Pod is started, the OPA controller generates an authentication policy set related to the corresponding Pod based on the Pod label, and filters the authentication policy set;

[0026] In the event of an OPA controller restart, network problems, or other abnormal situations, 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.

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

[0028] According to the Pod's namespace, find the corresponding label-policy ID mapping table;

[0029] Perform a pre-query operation, traverse all Pod labels, search for a policy ID set matching each Pod label in the label-policy ID mapping table, merge all the found policy ID sets to obtain a union set, and the union set contains all policy IDs associated with the Pod label;

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

[0031] According to the union set after the filtering operation, a corresponding resource list is output.

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

[0033] In the second aspect, the present application also provides a network authentication device based on ISTIO and OPA, including:

[0034] Configuration module, used to deploy service proxy Envoy and OPA Agent in sidecar mode in the smallest deployment unit Pod containing OPA;

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

[0036] The configuration module is also used to customize the content and scope of OPA's authentication policy 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 the synchronization compensation mechanism;

[0038] An index module, used to build an inverted index when starting the system or updating the system regularly, mapping the label of each authentication policy to a list of resources with corresponding labels;

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

[0040] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

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

[0042] Preset ServiceEntry resources and ExtensionProvider resources to enable Envoy to transparently transmit traffic to OPAAgent for authentication;

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

[0044] Use the synchronization compensation mechanism to synchronize the authentication policy to the corresponding Pod in a multi-cluster environment;

[0045] When starting the system or updating the system regularly, build an inverted index 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 a corresponding resource list.

[0047] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the following steps are implemented:

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

[0049] Preset ServiceEntry resources and ExtensionProvider resources to enable Envoy to transparently transmit traffic to OPAAgent for authentication;

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

[0051] Use the synchronization compensation mechanism to synchronize the authentication policy to the corresponding Pod in a multi-cluster environment;

[0052] When starting the system or updating the system regularly, build an inverted index 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 a corresponding resource list.

[0054] In a fifth aspect, the present application further provides a computer program product, including a computer program, which implements the following steps when executed by a processor:

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

[0056] Preset ServiceEntry resources and ExtensionProvider resources to enable Envoy to transparently transmit traffic to OPAAgent for authentication;

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

[0058] Use the synchronization compensation mechanism to synchronize the authentication policy to the corresponding Pod in a multi-cluster environment;

[0059] When starting the system or updating the system regularly, build an inverted index 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 a corresponding resource list.

[0061] The above-mentioned network authentication method, device, computer equipment, computer-readable storage medium and computer program product based on ISTIO and OPA reduce the need for manual configuration and reduce the complexity of operation by automatically managing and optimizing the calculation, distribution and retrieval of policies, making the network authentication process more efficient and easy to manage. Combining the capabilities of Istio and OPA, a powerful network authentication solution is provided to enhance 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, so that policies can flexibly adapt to different business needs and security requirements. The synchronous compensation mechanism is used to ensure that the authentication policy can be correctly and consistently synchronized to the corresponding Pod in a multi-cluster environment, maintaining the consistency of policy execution. By constructing an inverted index, the performance of resource retrieval based on labels is optimized, especially in large-scale environments, and related resources and policies can be quickly found and matched according to labels. Automated and optimized policy management reduces the workload of operation and maintenance, reduces the risks caused by configuration errors, and thus reduces the related operation and maintenance costs. The use of inverted indexes increases the speed of finding and matching policies, allowing the system to respond to authentication requests faster and improve user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

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

[0064] Figure 2 A flowchart of a calculation process of calculating an OPA policy result set matching a pod in another embodiment is shown;

[0065] Figure 3 A schematic diagram of a compensation mechanism in an embodiment of the present application;

[0066] Figure 4 A schematic diagram of an inverted index in an embodiment of the present application;

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

[0068] Figure 6 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0069] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0070] Istio is a common service mesh architecture, which is 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 separate network issues from the underlying applications. Applications only send or receive messages to or from localhost without understanding the network topology.

[0071] The combination of Istio and OPA can conveniently manage the authentication logic of the entire network, and both are deployed in a sidecar manner, without intruding into the business for modification. However, the community's combination solution requires manual configuration of Envoy Filter, OPA startup Config Map, OPA Config Map resources, and release of OPA ports, etc. The threshold for use is very high, and online changes cannot be made. In a large grid, multiple policies and multiple namespaces need to take effect, which obviously cannot be achieved simply by relying on Config Map.

[0072] The present invention aims to provide a network authentication method based on ISTIO and OPA to solve the deficiencies of the prior art. Its main features are:

[0073] 1. Remove the manually configured logic 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 release OPA's business port.

[0077] 2. Provide a custom resource (CRD) OPA Policy, which can customize the policy content and effective scope of OPA for users, and automatically calculate and send it to the corresponding pod to take effect.

[0078] 3. Provide a synchronization compensation mechanism to ensure that the policy definition can still be synchronized to the corresponding pod in the case of cluster addition / removal, abnormal program crash, etc. in a multi-cluster environment.

[0079] 4. Based on the inverted index, optimize the memory retrieval of tags to improve performance.

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

[0081] Step S102: In the smallest deployment unit Pod including OPA, the service proxy Envoy and OPA Agent are deployed in sidecar mode.

[0082] Specifically, in Kubernetes, a Pod is the smallest deployment unit and can contain one or more containers. Pod containing OPA: This means that an OPA container has been deployed in a Pod. OPA acts as a policy engine to evaluate and execute policy-based decisions.

[0083] Among them, the sidecar pattern is a common microservice architecture pattern, in which a main container (usually an application container) is deployed in the same Pod with one or more auxiliary containers (sidecar containers). Sidecar containers are usually responsible for auxiliary tasks such as log collection, monitoring, network proxy, etc.

[0084] Among them, Envoy is a high-performance service proxy used to handle network traffic between services, including traffic forwarding, routing, health checks, etc. In the service mesh architecture, Envoy is often used as a core component of the data plane. In this Pod, Envoy is deployed as a sidecar container of OPA. In this way, Envoy can be closely integrated with OPA and use OPA's policy decision-making capabilities to manage traffic. This deployment method allows Envoy to give traffic decision-making authority to OPA, realizing traffic control and authentication based on OPA policies. At the same time, this also means that Envoy's configuration (such as ServiceEntry, ExtensionProvider) can be automatically generated, and OPA's business ports can be automatically configured to be released to facilitate communication between Envoy and OPA, allowing flexible deployment and management of OPA and Envoy integration in a Kubernetes environment, so as to use OPA's policy decision-making capabilities to manage and control network traffic between microservices.

[0085] In an exemplary embodiment, in the process of deploying the service proxy Envoy and OPA Agent in sidecar mode in the smallest deployment unit Pod including OPA, the Config Map resources are removed through the OPA sidecar, and the listening address and policy evaluation path of OPA are configured through the container startup parameters.

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

[0087] The container startup parameters are the parameters passed to the container application or service when the container is started. These parameters can be used to configure the application behavior inside the container.

[0088] Among them, OPA's listening address and policy evaluation path are no longer configured through Config Map, but are directly passed through container startup parameters. In this way, the configuration of the OPA container can be set directly when it is started without relying on external ConfigMap 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 of the OPA container include:

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

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

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

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

[0110] Step S104, pre-set ServiceEntry resources and ExtensionProvider resources to enable Envoy to transparently transmit traffic to OPA Agent for authentication.

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

[0112] Extension Provider resources are used to configure Envoy to use external services such as OPA for specific operations, such as authentication decisions. By defining an Extension Provider, you can specify the service name and port that Envoy uses to communicate with OPA, as well as the configuration of authentication behavior. This includes setting up Envoy to communicate with OPA over gRPC and defining how authentication requests and responses are handled.

[0113] OPA's business ports are the network ports that OPA uses to receive and respond to Envoy authentication queries. In order for Envoy to be able to transfer decision-making authority for authentication traffic to the OPA sidecar, you need to ensure that OPA's business ports are open to Envoy. This usually involves allowing these ports in Istio's network policy to avoid any network access control rules 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 an authentication request to OPA and decides whether to release the request based on OPA's response (allow or deny). This integration allows flexible and dynamic policies based on OPA to control communication between services, providing a fine-grained access control mechanism.

[0115] In an exemplary embodiment, ServiceEntry resources and ExtensionProvider resources are pre-set to enable Envoy to transparently transmit traffic to OPA Agent for authentication, including:

[0116] Define the service through the Service Entry resource, specify the host name and port of the service entry so that Istio can route traffic to OPA;

[0117] Open the OPA service port and configure Envoy through the Extension Provider resource so that Envoy transfers the decision-making authority of authentication traffic to the OPA sidecar;

[0118] Configure the access control policy in Istio through the Authorization Policy resource, specify the services that require OPA authorization check, and reference the OPA service defined in the Extension Provider resource.

[0119] Specifically, define services through Service Entry resources: Service Entry resources are used to define access rules for external services in the Istio service mesh. In this context, it is used to specify how to access the OPA service. By defining a Service Entry, you can specify the hostname and port of the OPA service, which allows Istio to route traffic to OPA. In this way, when Envoy needs to make an authentication decision, it can send the request to OPA.

[0120] Configuring Envoy through Extension Provider resources: Extension Provider resources are used to configure Envoy to use external services (such as OPA) for specific operations, such as authentication decisions. Through Extension Provider, Envoy is configured to make decisions about authentication traffic. This involves specifying the service name and port for communication with OPA, as well as the configuration of the authentication behavior. In order for Envoy to communicate with OPA, OPA's business ports need to be opened. This usually involves releasing these ports in Istio's network policy to avoid any network access control rules blocking communication between Envoy and OPA.

[0121] Configure access control policies through Authorization Policy resources: Authorization Policy resources are used to configure access control policies in Istio and specify which services require OPA authorization checks. In AuthorizationPolicy, by referencing the OPA service defined in the Extension Provider resource, you can ensure that Envoy sends authentication requests to the correct OPA service instance.

[0122] The following are specific embodiments:

[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 routes traffic to OPA. This YAML file defines a ServiceEntry named "ext-authz". It is used to configure service entry rules in the Istio service mesh. It specifies the host name and port of a service entry and how to route traffic to a specific endpoint. This configuration allows Istio to import traffic to a service named "ext-authz.opa-istio.internal" and specifies the port number 19191.

[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 so that Envoy can delegate decision-making authority for authentication traffic. This YAML file defines an extension provider called "opa-ext-authz-grpc". It is 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 also configures some authentication behavior options, such as whether to allow part of the request body to be included in the authentication check. The corresponding envoyExtAuthzGrpc.service corresponds to the spec.hosts of the above ServiceEntry.

[0156] Authorization Policy Example:

[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". It is used to configure the access control policy in Istio. It specifies the application label selector to which the authorization policy is to apply, as well as the custom authorization provider name and authorization rules to use. Here, it applies the authorization policy to the application with the label "app:productpage" and the trigger condition is that the request path matches " / *". Where provider.name corresponds to the extensionProviders.name of the above external authorization policy.

[0170] In summary, by configuring Istio to generate Service Entry resources and Extension Provider resources and opening OPA's business ports, Envoy and OPA can be integrated, enabling Envoy to delegate decision-making authority over authentication traffic. This integration provides a flexible and scalable way to implement fine-grained access control and authentication policies.

[0171] Step S106, customize the content and effective scope of OPA's authentication policy by configuring OPA Policy resources.

[0172] Specifically, OPA Policy is a Kubernetes custom resource definition (CRD), which allows users to define and manage OPA policies in a declarative manner in a Kubernetes cluster. In the OPA Policy resource, users can write specific policy logic, which is usually expressed in OPA's Rego language. Rego is a declarative logic language specifically designed for writing and querying policies.

[0173] Users define the specific content of the authentication policy in OPA Policy, such as which users can access which resources, or under what conditions to allow or deny requests. These policies can be dynamically loaded into OPA, which means that the policy can be updated without restarting the service, achieving hot updates. The scope of the defined policy includes namespace isolation and label selectors.

[0174] Through OPA Policy resources, users can automatically manage and distribute authentication policies without manually modifying configuration files or redeploying services. In a multi-cluster environment, changes to OPA Policy resources can be synchronized to all related clusters to ensure the 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 are customized, including:

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

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

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

[0179] Among them, the workload selector (WorkloadSelector) includes: Namespace Isolator: Through the namespace isolator, OPA Policy can specify that the policy is only effective in a specific Kubernetes namespace, thereby achieving namespace-level isolation. Kubernetes label selector: Using the Kubernetes label selector, OPA Policy can further refine the scope of the policy so that the policy only applies to resources with specific labels (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 to allow or deny requests.

[0181] In 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 specific authentication logic.

[0182] The following is an example configuration of 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 is effective for resources with the tag app:my-app. The policy field contains the policy content written in Rego syntax, which defines the access control logic based on user roles. In this example, the policy means: if you log in with the guest group, you can only access / productpage. If you log in with the admin group, you can access both / productpage and / api / v1 / products. Guest1 belongs to the guest group, and admin1 belongs to the admin group.

[0227] In this embodiment, by configuring the OPA Policy resources and OPA Policy Spec structure, users can customize the content and scope of OPA's authentication policy to achieve 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: Synchronize the authentication policy to the corresponding Pod in a multi-cluster environment by using the synchronization compensation mechanism.

[0229] Specifically, in a multi-cluster environment, different clusters may be distributed in different geographical locations or data centers. In order to ensure that all Pods in all clusters follow the same authentication policy, when the policy is updated, the changes are quickly and accurately synchronized to all clusters, and in the event of network partitions, cluster failures or other abnormal situations, the policy synchronization and consistency are maintained. The authentication policy is synchronized to the corresponding Pod in a multi-cluster environment using a synchronization compensation mechanism.

[0230] Among them, the synchronous 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. Monitoring and event delivery:

[0232] OPA controller monitoring: A dedicated OPA controller (Kubernetes controller) monitors the addition, deletion, and modification 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] Synchronize when Pod starts: When a Pod starts, the OPA controller synchronizes all relevant policies to the Pod based on the Pod's labels and namespaces.

[0236] Filter by label: The OPA controller filters out the policy set that matches the Pod based on the Pod's label, ensuring that only relevant policies are applied to the Pod.

[0237] 3. Regular recalculation:

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

[0239] Exception handling: When an abnormal situation occurs (such as OPA controller restart, network problems, etc.), recalculating tasks can help restore data consistency and ensure that policies are correctly synchronized to all Pods.

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

[0241] The OPA controller monitors the addition, deletion, and modification events of OPA Policy resources, and synchronizes abnormal events in the addition, deletion, and modification events to the affected Pods.

[0242] When the Pod is started, the OPA controller generates an authentication policy set related to the corresponding Pod based on the Pod label, and filters the authentication policy set;

[0243] In the event of an OPA controller restart, network problems, or other abnormal situations, 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.

[0244] Specifically, the OPA controller is a specialized controller responsible for managing OPA Policy resources. It monitors any changes to these resources, including creation, update, and deletion (add, delete, and modify) events. When the OPA controller detects changes to OPA Policy resources, it synchronizes these changes (especially abnormal events) to the affected Pods. This ensures that the policies in the Pods are always up to date and can respond to policy changes in a timely manner.

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

[0246] In abnormal situations such as when the OPA controller restarts or network problems occur, policy synchronization may be interrupted. To solve this problem, the OPA controller periodically updates the status of the authentication policy. This regular update mechanism ensures that even in a multi-cluster environment, the authentication policy can be correctly and consistently synchronized to all corresponding Pods, maintaining the consistency and correctness of the policy.

[0247] The synchronization compensation mechanism ensures that in a multi-cluster environment, all Pods can receive the latest authentication policies in a timely manner, regardless of which cluster they are located. Through regular updates and abnormal event handling, the system can remain stable in the face of network problems or controller failures, reducing the risk of policy synchronization failures. Through the monitoring and synchronization mechanism, the system can respond quickly to policy changes, improving the response speed and overall performance of policy changes.

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

[0249] Step S110: when starting the system or updating the system regularly, construct an inverted index to map the label of each authentication policy to a list of resources with corresponding labels.

[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 that contain those words. In the context of authentication policies, an inverted index maps the labels of a policy to resources (such as Pods) with those labels. With an inverted index, you can quickly find relevant policies based on labels instead of traversing all policies, thereby improving retrieval efficiency. In large-scale environments, an inverted index can significantly reduce the time required to find resources with specific labels and improve system response speed.

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

[0252] It should be noted that after obtaining the results in reverse sorting, the pre-query results need to be filtered in forward sorting, that is, all labels in union_policy_ids are traversed, and the workloadSelector label set with complete policy details is compared one by one to see whether it is completely included in the pod label.

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

[0254] Specifically, first, determine the preset tags that need to be queried. These tags may be defined by the policy 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 that have the tags specified during the query. In the authentication policy, the inverted index can be used to quickly find the resources that need to apply a specific policy.

[0255] In the above network authentication method based on ISTIO and OPA, the calculation, distribution and retrieval of policies are automatically managed and optimized, which reduces the need for manual configuration, reduces the complexity of operation, and makes the network authentication process more efficient and easy to manage. Combining the capabilities of Istio and OPA, a powerful network authentication solution is provided to enhance 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, so that policies can flexibly adapt to different business needs and security requirements. The synchronization compensation mechanism is used to ensure that authentication policies can be correctly and consistently synchronized to the corresponding Pods in a multi-cluster environment, maintaining the consistency of policy execution. By building an inverted index, the performance of resource retrieval based on labels is optimized, especially in large-scale environments, and related resources and policies can be quickly found and matched according to labels. Automated and optimized policy management reduces the workload of operation and maintenance, reduces the risks caused by configuration errors, and thus reduces the related operation and maintenance costs. The use of inverted indexes increases the speed of finding and matching policies, allowing the system to respond to authentication requests faster and improve user experience.

[0256] In an exemplary embodiment, the inverted index is queried to obtain a corresponding resource list, such as Figure 2 As shown, including:

[0257] Step S202: search the corresponding label-policy ID mapping table according to the namespace of the Pod;

[0258] Step S204, performing a pre-query operation, traversing all Pod labels, searching for a policy ID set matching each Pod label in the label-policy ID mapping table, merging all the found policy ID sets to obtain a union set, and the union set includes all policy IDs associated with the Pod label;

[0259] Step S206, performing a filtering operation, traversing each policy ID in the union set, and verifying whether the complete label set of each policy ID completely matches the complete label set of the corresponding Pod;

[0260] Step S208: output a corresponding resource list according to the union set after the filtering operation.

[0261] Specifically, Figure 3 As shown in the figure, first, the system searches the pre-built inverted index for the mapping table of corresponding labels to policy IDs according to the namespace to which the Pod belongs (i.e. Figure 4 This mapping table contains the labels of all policies in the namespace and their corresponding policy IDs.

[0262] Next, the system performs a pre-query operation and iterates over all labels on the Pod. For each label, the system searches the label-to-policy ID mapping table for a set of policy IDs that matches the label. All policy ID sets found are merged to form a union set, union_policy_ids, which contains all policy IDs associated with the Pod label.

[0263] Next, the system performs a filtering operation, traversing each policy ID in union_policy_ids to verify whether the complete label set corresponding to each policy ID completely matches the complete label set of the Pod. Only when the label set of the policy is completely contained in the label set of the Pod, the policy is considered to match the Pod.

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

[0265] In this embodiment, through the inverted index, the system can quickly find and match relevant policies based on the label, improving the retrieval efficiency. The screening operation ensures that only policies that fully match the Pod label 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, which allows the system to quickly and accurately retrieve and apply relevant authentication policies based on the Pod's label.

[0266] In a specific embodiment, Figure 3As shown, the opa-controller still needs to start alignment and periodically recalculate to ensure that there is a chance to align the data under abnormal circumstances.

[0267] Scheduled calculation requires pulling all pods and policies, as well as comparing the policies that have been pulled by each pod, and finally controlling the delivery of the difference set. Excessive policies are deleted, and changed or missing policies are put.

[0268] Since we need to find the range of pods through the label of the policy, we also need to find the set of policies based on the label of the pod. Obviously, it is easy to find pods through policies, but finding policies through pods requires the introduction of an inverted index. Considering that some policies have no labels, such as Figure 4 As shown, all pods in the namespace are effective, and a namespace map (referred to as map1) is maintained. In addition, all policy labels are used to create a label->policy_id map (referred to as map2). The policy_id to policySpec can be cached in K8S, which is referred to as policy_id_Map.

[0269] After the opa controller is started, it traverses all policies, obtains the corresponding labels, and creates indexes.

[0270] Add policy: traverse the corresponding label and add policy_id to the policy_id_set of the corresponding label.

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

[0272] Update the policy, traverse all labels, query and update map2.

[0273] The pod matches which policies need to go through the following steps:

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

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

[0276] 3. Because the policy may have other filtering conditions, the above unions are the results of reverse sorting of a single label, and the pre-query results need to be filtered in forward sorting. That is, all labels in union_policy_ids are traversed, and the workloadSelector label set with complete policy details is compared one by one to see if it is completely included in the pod label.

[0277] 4. Return the final result set.

[0278] Here is an example:

[0279] Assume that pod1 has labels L1, L2, and L3. Now, in the same namespace, there are:

[0280] Policy1: no label;

[0281] Policy2: L1;

[0282] Policy3: L3, L4;

[0283] Policy4: L4;

[0284] The constructed inverted list is:

[0285] L1->Policy2;

[0286] L3->Policy3;

[0287] L4->Policy3, Policy4;

[0288] The query process is:

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

[0290] Pre-query, Policy1 has no label and meets the conditions. L1 reverses to Policy2, but there is no result for L2. L3 reverses to Policy3, and union_policy_ids is Policy{1,2,3};

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

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

[0293] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0294] Based on the same inventive concept, the embodiment of the present application also provides a network authentication device based on ISTIO and OPA for implementing the network authentication method based on ISTIO and OPA involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more embodiments of the network authentication device based on ISTIO and OPA provided below can be referred to the limitations of the network authentication method based on ISTIO and OPA above, and will not be repeated here.

[0295] In an exemplary embodiment, Figure 5 As shown, a network authentication device based on ISTIO and OPA is provided, including: a configuration module 502, which is used to deploy service proxy Envoy and OPA Agent in a sidecar mode in a minimum deployment unit Pod including OPA;

[0296] Configuration module 502 is also used to preset ServiceEntry resources and ExtensionProvider resources so that Envoy can transparently transmit traffic to OPA Agent for authentication;

[0297] The configuration module 502 is also used to customize the content and effective scope of the OPA authentication policy by configuring the OPA Policy resources;

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

[0299] An index module 506, used to construct an inverted index when starting the system or updating the system regularly, and map the label of each authentication policy to a list of resources with corresponding labels;

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

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

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

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

[0304] In an exemplary embodiment, the synchronization module 504 is specifically used to monitor the addition, deletion, and modification events of OPAPolicy resources through the OPA controller, and synchronize the abnormal events in the addition, deletion, and modification events to the affected Pods; when the Pod is started, the OPA controller generates an authentication policy set related to the corresponding Pod according to the Pod label, and filters the authentication policy set; when the OPA controller is restarted, network problems occur, or other abnormal situations occur, the OPA controller regularly 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 index module 506 is specifically used to find the corresponding label-policy ID mapping table according to the namespace of the Pod; perform a pre-query operation, traverse all Pod labels, find the policy ID set that matches each Pod label in the label-policy ID mapping table, merge all the found policy ID sets to obtain a union set, and the union set includes all policy IDs associated with the Pod label; perform a filtering operation, traverse each policy ID in the union set, and verify whether the complete label set of each policy ID is completely matched with the complete label set of the corresponding Pod; and output the corresponding resource list according to the union set after the filtering operation.

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

[0307] Each module in the above-mentioned network authentication device based on ISTIO and OPA can be implemented in whole or in part by software, hardware and their combination. Each of the above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to each of the above modules.

[0308] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 6 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a network authentication method based on ISTIO and OPA is implemented.

[0309] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the above steps when executing the computer program.

[0310] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the method of the above steps is implemented.

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

[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, stored data, displayed data, 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 relevant data must comply with relevant regulations.

[0313] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present 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. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0314] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, 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 above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A network authentication method based on ISTIO and OPA, characterized in that: The method comprises: In the smallest deployment unit Pod that includes OPA, deploy the service proxy Envoy and OPA Agent in sidecar mode; Preset ServiceEntry resources and ExtensionProvider resources to enable Envoy to transparently transmit traffic to OPA Agent for authentication; By configuring OPA Policy resources, you can customize the content and scope of OPA's authentication policy. Use the synchronization compensation mechanism to synchronize the authentication policy to the corresponding Pod in a multi-cluster environment; When starting the system or updating the system regularly, build an inverted index to map the label of each authentication policy to a list of resources with the corresponding label; When it is necessary to find resources with preset tags, the inverted index is queried to obtain a corresponding resource list.

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

3. The method according to claim 1, characterized in that The ServiceEntry and ExtensionProvider resources are pre-set to enable Envoy to transparently transmit traffic to the OPA Agent for authentication, including: Define the service through the Service Entry resource, specify the host name and port of the service entry so that Istio can route traffic to OPA; Open the OPA service port and configure Envoy through the Extension Provider resource so that Envoy transfers the decision-making authority of authentication traffic to the OPA sidecar; Configure the access control policy in Istio through the Authorization Policy resource, specify the services that require OPA authorization check, and reference the OPA service defined in the Extension Provider resource.

4. The method according to claim 1, characterized in that: The OPA Policy resource includes an OPA PolicySpec structure; By configuring OPA Policy resources, the content and scope of OPA's authentication policy can be customized, including: 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, and both the namespace isolator and the Kubernetes label selector are used to specify the effective scope of the authentication policy; the authentication policy field includes the policy content written in Rego syntax.

5. The method according to claim 1, characterized in that The synchronization compensation mechanism is used to synchronize the authentication policy to the corresponding Pod in a multi-cluster environment, including: The OPA controller monitors the addition, deletion, and modification events of OPA Policy resources, and synchronizes abnormal events in the addition, deletion, and modification events to the affected Pods. When the Pod is started, the OPA controller generates an authentication policy set related to the corresponding Pod based on the Pod label, and filters the authentication policy set; In the event of an OPA controller restart, network problems, or other abnormal situations, 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.

6. The method according to claim 1, characterized in that The querying the inverted index to obtain a corresponding resource list includes: According to the Pod's namespace, find the corresponding label-policy ID mapping table; Perform a pre-query operation, traverse all Pod labels, search for a policy ID set matching each Pod label in the label-policy ID mapping table, merge all the found policy ID sets to obtain a union set, and the union set contains all policy IDs associated with the Pod label; 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; According to the union set after the filtering operation, a corresponding resource list is output.

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

8. A network authentication device based on ISTIO and OPA, characterized in that: The device comprises: Configuration module, used to deploy service proxy Envoy and OPA Agent in sidecar mode in the smallest deployment unit Pod containing OPA; The configuration module is also used to pre-set ServiceEntry resources and ExtensionProvider resources so that Envoy can pass traffic to OPA Agent for authentication; The configuration module is also used to customize the content and scope of OPA's authentication policy 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 the synchronization compensation mechanism; An index module, used to build an inverted index when starting the system or updating the system regularly, mapping the label of each authentication policy to a list of resources with corresponding labels; The index module is also used to query the inverted index and obtain a corresponding resource list when it is necessary to find resources with preset tags.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

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

Images