Software authorization control method and device and storage medium

Abstract

The invention relates to a software authorization control method and device and a storage medium, and the method comprises the steps: obtaining authorization strategy configuration comprising a service name; determining a target business deployment unit based on the service name, and injecting the access agent component into the target business deployment unit; performing format conversion on the authorization policy configuration to generate a native access control policy, and pushing the native access control policy to the access agent component; responding to an external data verification authorization request and analyzing the request to obtain a request index name, a request service name and a request rule name; acquiring real-time index data sent by an index storage system; determining an index restriction expression and an authorization response corresponding to the index restriction expression based on the request rule name; and generating an authorization result based on the real-time index data, the index limitation expression and the authorization response. According to the invention, the problems that the authorization control management is complex and the control failure is easy to occur are solved.

Description

Technical Field

[0001] The present application relates to the technical field of computer application software authorization management, and in particular to a software authorization control method, device, and storage medium. Background Art

[0002] In the fields of computer application software license management and cloud-native technologies, software license control is a critical component in ensuring software compliance and balancing developer rights and user needs. Common software license control methods include hardware binding (such as MAC address or CPU serial number binding), online activation verification, and dongle or license file verification. These methods can be effective in single-machine or fixed cluster environments. However, in large-scale private deployment projects in the ICT sector, modern systems generally adopt a cloud-native microservices architecture, consisting of hundreds or even thousands of microservices developed collaboratively across multiple departments. For example, one ICT project deployed hundreds of business Pods (Pods) for modules such as access aggregation, view storage, and baseline applications in a Kubernetes cluster, all developed by different business departments. While this architecture improves system flexibility and scalability, it also presents numerous challenges for software license control. Related technologies struggle to adapt to the demands of large-scale distributed systems, making license control complex to manage and prone to control failures in large-scale distributed systems built on cloud-native microservices architectures.

[0003] Currently, no effective solution has been proposed to address the problem that authorization control in related technologies is complex to manage and prone to control failure in large-scale distributed systems of cloud-native microservice architecture. Summary of the Invention

[0004] The embodiments of the present application provide a software authorization control method, device, and storage medium to at least solve the problem in related technologies that authorization control is complex to manage and prone to control failure in large-scale distributed systems of cloud-native microservice architectures.

[0005] In a first aspect, an embodiment of the present application provides a software authorization control method, applied to a control plane, the method comprising:

[0006] Obtaining authorization policy configuration; the authorization policy configuration includes a service name;

[0007] Based on the service name, a target business deployment unit is determined from multiple business deployment units in the data plane, and a preset access proxy component is injected into the target business deployment unit in the data plane; the authorization policy configuration is formatted to obtain a native access control policy, and the native access control policy is pushed to the access proxy component in the target business deployment unit;

[0008] In response to the external data verification authorization request sent by the data plane, the external data verification authorization request is parsed to obtain a request indicator name, a request service name, and a request rule name; the external data verification authorization request is sent by the access proxy component based on the native access control policy;

[0009] Acquire real-time indicator data sent by the indicator storage system of the data plane; the real-time indicator data corresponds to the requested indicator name and the requested service name;

[0010] Determine, based on the request rule name, an indicator restriction expression and an authorization response corresponding to the indicator restriction expression;

[0011] An authorization result is generated based on the real-time indicator data, the indicator restriction expression and the authorization response.

[0012] In some embodiments, the method of obtaining the authorization policy configuration includes online acquisition and offline acquisition;

[0013] When the method for obtaining the authorization policy configuration is online acquisition, the authorization policy configuration is obtained from the unified authorization management platform by calling a preset interface of the unified authorization management platform;

[0014] When the method for obtaining the authorization policy configuration is offline acquisition, the preset authorization file is imported into the preset indicator authentication service to obtain the authorization policy configuration.

[0015] In some embodiments, determining a target service deployment unit from a plurality of service deployment units in a data plane based on the service name, and injecting a preset access proxy component into the target service deployment unit in the data plane includes:

[0016] Based on the service name, determining the target business deployment unit from the multiple business deployment units, and setting a component injection flag of the target business deployment unit through a preset service grid management and control component;

[0017] Based on the component injection mark, the access proxy component is injected into the target service deployment unit.

[0018] In some embodiments, injecting the access proxy component into the service deployment unit based on the component injection mark includes:

[0019] In a case where the component injection flag is in a set state, the access proxy component is injected into the service deployment unit.

[0020] In some embodiments, generating an authorization result based on the real-time indicator data, the indicator restriction expression, and the authorization response corresponding to the indicator restriction expression includes:

[0021] Bringing the real-time indicator data into the indicator restriction expression for calculation to obtain a calculation result;

[0022] The authorization result is generated based on the calculation result, the indicator restriction expression and the authorization response.

[0023] In some embodiments, the authorization response includes permission or rejection; and generating the authorization result based on the calculation result, the indicator restriction expression, and the authorization response includes:

[0024] In the case where the authorization response is allow, if the calculation result meets the conditions of the indicator restriction expression, it will be allowed as the authorization result;

[0025] In the case where the authorization response is allow, if the calculation result does not meet the conditions of the indicator restriction expression, rejection is used as the authorization result;

[0026] In the case where the authorization response is rejection, if the calculation result meets the conditions of the indicator restriction expression, rejection is taken as the authorization result;

[0027] In the case where the authorization response is a rejection, if the calculation result does not meet the conditions of the indicator restriction expression, it will be allowed as the authorization result.

[0028] In a second aspect, an embodiment of the present application provides a software authorization control method, applied to a data plane, the method comprising:

[0029] Obtaining an access proxy component injected by the control plane, and installing the access proxy component into a target service deployment unit determined by the control plane from a plurality of service deployment units of the data plane based on a service name; the service name is determined by the control plane based on the obtained authorization policy configuration;

[0030] Obtain the native access control policy sent by the control plane; the native access control policy is obtained by formatting the preset authorization policy configuration by the indicator authentication service of the control plane; the native access control policy includes the request method, request path and indicator name;

[0031] Loading the native access control policy into the access proxy component;

[0032] Obtain external data from the access proxy component; if the external data matches the request method and the request path, initiate an external data verification authorization request to the indicator authentication service of the control plane; the external data verification authorization request includes the request indicator name, the request service name, and the request rule name;

[0033] Regularly obtain multiple indicator data of the multiple business deployment units, and write the multiple indicator data into a preset indicator storage system after aggregating the multiple indicator data;

[0034] In response to a query request from the indicator authentication service, query the indicator storage system for real-time indicator data and send the real-time indicator data to the indicator authentication service; the real-time indicator data corresponds to the requested indicator name and the requested service name;

[0035] Obtaining an authorization result sent by the indicator authentication service; the authorization result is obtained by the indicator authentication service based on the real-time indicator data and the request rule name;

[0036] When the authorization result is rejection, the external data is processed according to the indicator name and the preset exception handling strategy.

[0037] In some embodiments, the authorization result is obtained by the indicator authentication service based on the request rule name, determining the indicator restriction expression and the authorization response corresponding to the indicator restriction expression; and is obtained based on the real-time indicator data, the indicator restriction expression and the authorization response.

[0038] In a third aspect, an embodiment of the present application provides a software authorization control device, applied to a control plane, comprising:

[0039] An authorization policy acquisition module is used to obtain an authorization policy configuration; the authorization policy configuration includes a service name;

[0040] An access proxy injection and policy push module is used to determine a target business deployment unit from multiple business deployment units in the data plane based on the service name, and inject a preset access proxy component into the target business deployment unit in the data plane; convert the format of the authorization policy configuration to obtain a native access control policy, and push the native access control policy to the access proxy component in the target business deployment unit;

[0041] a verification request parsing module, configured to respond to an external data verification authorization request sent by the data plane, parse the external data verification authorization request, and obtain a request indicator name, a request service name, and a request rule name; the external data verification authorization request is sent by the access proxy component based on the native access control policy;

[0042] A real-time indicator data acquisition module, configured to acquire real-time indicator data sent by the indicator storage system of the data plane; the real-time indicator data corresponds to the request indicator name and the request service name;

[0043] An authorization rule determination module, configured to determine an indicator restriction expression and an authorization response corresponding to the indicator restriction expression based on the request rule name;

[0044] The authorization result generation module is used to generate an authorization result based on the real-time indicator data, the indicator restriction expression and the authorization response.

[0045] In a fourth aspect, an embodiment of the present application provides a storage medium on which a computer program is stored. When the program is executed by a processor, the software authorization control method as described in the first and second aspects above is implemented.

[0046] Compared with the related art, the software authorization control method, device and storage medium provided in the embodiments of the present application, the software authorization control method, is applied to the control plane, by obtaining the authorization policy configuration; the authorization policy configuration includes a service name; based on the service name, the target business deployment unit is determined from multiple business deployment units of the data plane, and the preset access proxy component is injected into the target business deployment unit in the data plane; the authorization policy configuration is formatted to obtain a native access control policy, and the native access control policy is pushed to the access proxy component in the target business deployment unit; in response to the external data verification authorization request sent by the data plane, the external data verification authorization request is parsed to obtain the request indicator name, request service name and request rule name; the external data verification authorization request is sent by the access proxy component based on the native access control policy; real-time indicator data sent by the indicator storage system of the data plane is obtained; the real-time indicator data corresponds to the request indicator name and the request service name; based on the request rule name, the indicator restriction expression and the authorization response corresponding to the indicator restriction expression are determined; based on the real-time indicator data, the indicator restriction expression and the authorization response, an authorization result is generated, which solves the problem that authorization control is complex to manage and prone to control failure in large-scale distributed systems of cloud-native microservice architectures.

[0047] The details of one or more embodiments of the present application are set forth in the following drawings and description to make other features, objects, and advantages of the present application more readily apparent. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0049] Figure 1 This is a hardware structure block diagram of a terminal according to a software authorization control method according to an embodiment of the present application;

[0050] Figure 2 is a flowchart of a software authorization control method according to an embodiment of the present application;

[0051] Figure 3 is a flowchart of another software authorization control method according to an embodiment of the present application;

[0052] Figure 4 is a flow chart of external data authorization control according to an embodiment of the present application;

[0053] Figure 5 is a system architecture diagram of a software authorization control method according to an embodiment of the present application;

[0054] Figure 6 This is a structural block diagram of a software authorization control device according to an embodiment of the present application. DETAILED DESCRIPTION

[0055] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application is described and illustrated below in conjunction with the accompanying drawings and examples. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. Based on the embodiments provided in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application. In addition, it can also be understood that although the efforts made in this development process may be complex and lengthy, for ordinary technicians in the field related to the contents disclosed in the present application, some changes such as design, manufacturing or production based on the technical contents disclosed in the present application are only conventional technical means and should not be understood as the contents disclosed in the present application being insufficient.

[0056] References to "embodiments" in this application mean that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it refer to independent or alternative embodiments that are mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described in this application may be combined with other embodiments unless there is a conflict.

[0057] Unless otherwise defined, technical or scientific terms used herein shall have the ordinary meaning as understood by persons of ordinary skill in the art to which this application belongs. The terms "a," "an," "an," "the," and similar expressions used herein do not denote limitations on quantity and may refer to either the singular or the plural. The terms "comprise," "include," "have," and any variations thereof, used herein, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or modules (units) is not limited to the listed steps or units but may also include steps or units not listed, or may include other steps or units inherent to the process, method, product, or apparatus. The terms "connected," "connected," "coupled," and similar expressions used herein are not limited to physical or mechanical connections but may include electrical connections, whether direct or indirect. As used herein, "plurality" means greater than or equal to two. "And / or" describes an association between associated objects, indicating that three possible relationships exist. For example, "A and / or B" may mean: A exists alone; A and B exist simultaneously; or B exists alone. The terms "first", "second", "third" and the like involved in this application are merely used to distinguish similar objects and do not represent a specific ordering of the objects.

[0058] The method embodiment provided in this embodiment can be executed in a terminal, a computer or a similar computing device. Taking running on a terminal as an example, Figure 1 FIG is a hardware structure diagram of a terminal according to a software authorization control method of an embodiment of the present application. Figure 1 As shown, the terminal may include one or more ( Figure 1 Only one is shown) a processor 102 (the processor 102 may include but is not limited to a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data. Optionally, the terminal may also include a transmission device 106 and an input / output device 108 for communication functions. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above terminal. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0059] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the software authorization control method in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implementing the above-mentioned method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely located relative to the processor 102, and these remote memories may be connected to the terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0060] Transmission device 106 is used to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by the terminal's communications provider. In one embodiment, transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0061] Glossary:

[0062] Software licensing refers to the legal agreement (such as a license) that specifies the scope of a user's software rights, including usage methods, duration, quantity, and restrictions. Its core purpose is to control product distribution compliance through licensing models (such as subscription, perpetual license, and pay-as-you-go) and technical means (such as serial numbers, activation codes, and dongles), balancing developer rights and user needs to prevent piracy and abuse.

[0063] A service mesh is a dedicated communication infrastructure within a microservices architecture. It intercepts and manages inter-service traffic through sidecar proxies (such as Envoy), enabling non-intrusive traffic control (such as canary releases and load balancing), secure communication (mTLS encryption, RBAC authorization), and observability (metrics, logging, and tracing). Its core consists of a data plane (which handles actual traffic) and a control plane (which unifies policy configuration). Typical tools include Istio and Linkerd. It aims to simplify the operational complexity of distributed systems and improve reliability and security.

[0064] ICT (Information and Communication Technology): refers to the comprehensive technical field that uses computers, networks, communication technologies, etc. to process, store, transmit and manage information. It covers hardware, software, services and infrastructure, and is widely used in the digital construction of enterprises, governments and society.

[0065] Cloud Native: A methodology and technology system for designing, developing, and running applications in a cloud computing environment. It aims to leverage the cloud's elasticity, distribution, and automation to improve application scalability, reliability, and delivery efficiency. Its core concept is to enable applications to "be born and thrive in the cloud," rather than simply migrating traditional applications to the cloud.

[0066] In the fields of computer application software licensing management and cloud-native technologies, software licensing control is a critical step in ensuring software compliance and balancing developer rights and user needs. Common software licensing control methods include hardware binding (such as MAC address, CPU serial number), online activation verification, dongles, or license files. However, in large-scale private deployment projects in the ICT sector, modern systems typically adopt a cloud-native microservices architecture, consisting of hundreds or even thousands of microservices developed collaboratively across multiple departments. For example, one ICT project deployed 40 business Pods (PODs) for the access aggregation module, 17 business Pods for the view storage module, 40 business Pods for the baseline application module, 10 business Pods for the AI ​​analysis model, and 14 business Pods for the view big data module in a Kubernetes cluster. These Pods were developed by five business departments. While this architecture improves flexibility and scalability, it also introduces unprecedented complexity to software licensing control. Current software licensing technologies are primarily designed for single-machine or fixed cluster environments and are difficult to adapt to large-scale distributed systems. Key challenges include:

[0067] (1) Fragmentation of authorization strategies: Each business department independently implements the authorization mechanism, resulting in inconsistent authorization standards (some use hardware binding, some use license files), broken authorization verification chains during cross-service calls, and difficulty in globally monitoring the overall authorization status.

[0068] (2) Invalidation of dynamic resource and authorization binding: Cloud-native applications can automatically scale up and down (such as dynamic increase and decrease of Kubernetes Pods), but traditional authorization is bound to static hardware information (such as MAC addresses) or a fixed number of nodes, which causes authorization to become invalid after container drift (Pod restart / migration) or the new instance cannot automatically obtain legal authorization during automatic expansion, affecting business continuity.

[0069] (3) Coarse granularity of authorization control: Traditional solutions usually only control basic functions or the number of users, while modern ICT projects usually require more fine-grained authorization control, such as the number of device connections, the QPS (query rate per second) upper limit, and the number of GPU cannons. Existing technologies are difficult to support such multi-dimensional on-demand dynamic authorization control.

[0070] The software authorization control method of this embodiment mainly involves the data plane and the control plane. Among them, the control plane: includes the indicator authentication service and the service grid management component Istiod. It is mainly responsible for the distribution of authorization policies, processing the addition, deletion, modification and query of policies; responsible for querying indicator data and verifying the validity of policies; compiling authorization policies into an intermediate format, and distributing them to the access proxy component Envoy Sidecar through the xDS protocol; and automatically injecting the Envoy Sidecar that intercepts external requests into the business deployment unit (business Pod) on demand. Data plane: First, the access proxy component Envoy intercepts application traffic and performs actual authorization checks based on indicator data; second, the indicator collection component Porbe Pod, as an Exporter, adopts an active pull mode to obtain the indicator data exposed by the business Pod and reports it to the indicator storage system (Prometheus).

[0071] This embodiment provides a software authorization control method. Figure 2 This is a flowchart of a software authorization control method according to an embodiment of the present application, which is applied to the control plane, such as Figure 2 As shown, the process includes the following steps:

[0072] Step S201: Obtain authorization policy configuration; the authorization policy configuration includes a service name.

[0073] Specifically, obtaining authorization policy configuration is a fundamental step in the entire software authorization control method based on dynamic metric data. Its implementation balances the flexibility of online real-time acquisition and offline independent loading to adapt to the needs of different network environments and deployment scenarios. These configurations cover not only basic policy attributes such as name, description, effective start and end times, and current authorization status, but also key information such as associated accounts, roles, and service names. Furthermore, they include multiple rule items, each of which specifies the rule name, description, corresponding request method (e.g., POST, GET), request path (e.g., specific API interface path), associated metric name (e.g., number of connected devices, QPdevice_numS), metric constraint expression used to define the authorization boundary (e.g., "sum(probe_target_metric{metric=='device_num'})<=10"), authorization response (allow or deny) when the metric data meets or does not meet the expression, and exception handling strategies (e.g., graceful degradation when QPS exceeds the limit, entering read-only mode when authorization expires, etc.).

[0074] Step S202, based on the service name, determines the target business deployment unit from multiple business deployment units in the data plane, and injects the preset access proxy component into the target business deployment unit in the data plane; converts the authorization policy configuration format to obtain the native access control policy, and pushes the native access control policy to the access proxy component in the target business deployment unit.

[0075] Specifically, after obtaining the authorization policy configuration containing the service name, the control plane's indicator authentication service will first use the service name as the core identifier to accurately match the numerous business deployment units in the data plane (such as the business Pod in the K8S cluster) to locate the target business deployment unit to which the authorization policy should be applied. Subsequently, the preset access proxy component is injected into the target business deployment unit. At the same time as the access proxy component is injected, the indicator authentication service will convert the authorization policy configuration format, converting key information such as the service name, request path, request method, and indicator name into a native access control policy and push it to the injected access proxy component in the target business deployment unit. The access proxy component will automatically complete the hot reload of the configuration, allowing the new policy to take effect immediately without restarting, thus laying the foundation for subsequent interception of external requests and performing authorization checks. This approach ensures that the access proxy component is tightly bound to the target business deployment unit. Even if the business deployment unit drifts (such as Pod restart or migration), the access proxy component will follow synchronously and continuously maintain the existence of the policy execution carrier.

[0076] Step S203, in response to the external data verification authorization request sent by the data plane, parse the external data verification authorization request to obtain the request indicator name, request service name and request rule name; the external data verification authorization request is sent by the access proxy component based on the native access control policy.

[0077] Specifically, when the access proxy component of the target business deployment unit intercepts external data based on the loaded native access control policy, and the request method, request path and other information of the external data match the content defined in the native access control policy, the access proxy component will initiate an external data verification authorization request to the indicator authentication service of the control plane; after receiving the external data verification authorization request, the control plane will immediately respond and start the parsing process. By extracting and analyzing the request content, it can accurately obtain the request indicator name related to the current request (that is, the dynamic indicator that needs to be verified involved in the request, such as the number of device connections, QPS, etc.), the request service name (that is, the name of the target business service accessed by the request) and the request rule name (that is, the specific rule identifier in the authorization policy corresponding to the request); this parsing process is the key prerequisite for the subsequent control plane to query real-time indicator data, match indicator restriction expressions and generate authorization results. The entire external data verification authorization request initiation mechanism realizes the effective linkage between the data plane and the control plane regarding authorization verification, ensuring that the authorization check can be dynamically triggered based on the specific request scenario.

[0078] Step S204: Acquire real-time indicator data sent by the indicator storage system of the data plane; the real-time indicator data corresponds to the requested indicator name and the requested service name.

[0079] Specifically, in the data plane, the metric collection component (e.g., Probe Pod) uses an active pull model to periodically call various metric data query interfaces exposed by multiple business deployment units. These interfaces correspond to different business metrics (e.g., number of connected devices, QPS, number of GPUs, etc.). The metric collection component organizes the collected multi-dimensional metric data and remotely writes it to the metric storage system (e.g., Prometheus) by calling specific interfaces (e.g., " / api / v1 / write"), ensuring the continuous and accurate storage of real-time metric data. After parsing the external data verification authorization request and obtaining the requested metric name (e.g., "device_num") and the requested service name (e.g., "videocloud-device"), the control plane's metric authentication service initiates a precise query to the metric storage system based on these two key identifiers. The metric storage system then selects the corresponding metric type based on the requested metric name and, based on the requested service name, locates the metric data generated by the specific business deployment unit under that service. It then feeds the qualified real-time metric data (e.g., the current real-time statistics of the number of connected devices) back to the metric authentication service. This method of obtaining real-time data based strictly on the correspondence between the requested indicator name and the requested service name ensures that the indicator data used for subsequent authorization verification is targeted and timely, laying a solid data foundation for accurately judging whether the indicator meets the restrictions and generating correct authorization results. It also reflects the accuracy and relevance of data flow in the entire authorization control method.

[0080] Step S205: Determine the indicator restriction expression and the authorization response corresponding to the indicator restriction expression based on the request rule name.

[0081] Specifically, when the control plane's metric authentication service receives an external data verification authorization request and parses it to obtain the request rule name, it immediately searches the loaded authorization policy configuration based on that name, locates the corresponding rule item through precise matching, and then extracts the metric restriction expression used to determine the authorization boundary from that rule item. This expression typically contains calculation logic and threshold conditions for specific metrics (such as the number of connected devices and QPS), and also determines the authorization response type bound to the expression (i.e., whether to return "allow" or "reject" when the metric data satisfies the expression, and the corresponding response when it does not). This association mechanism based on the request rule name ensures that the preset judgment criteria can be accurately called during the real-time metric verification process, giving the generation of the authorization response a clear policy basis. This not only enables flexible binding of rules, metrics, and responses, but also ensures the consistency and traceability of the authorization logic, providing key rule support for subsequent substitution of real-time metric data for calculation and generation of the final authorization result.

[0082] Step S206: Generate an authorization result based on the real-time indicator data, the indicator restriction expression and the authorization response.

[0083] Specifically, the metric authentication service first obtains real-time metric data from a metric storage system (such as Prometheus) (this data strictly corresponds to the requested metric name and the requested service name, for example, the current value of the "device_num" metric for the "videocloud-device" service). This data is then substituted into a metric constraint expression specified by the request rule name (e.g., "sum(probe_target_metric{metric='device_num'})<=10") to calculate the specific result. The service then uses logical reasoning to determine the final authorization result, combined with the authorization response corresponding to the metric constraint expression (i.e., the preset "allow" or "deny" rule). This mechanism dynamically combines real-time service data with preset policy rules, enabling flexible authorization control based on actual service load while ensuring the objectivity and consistency of authorization decisions. This mechanism effectively supports fine-grained control of multi-dimensional metrics such as the number of connected devices and QPS, while also providing a basis for decision-making regarding exception handling (such as graceful degradation when QPS exceeds the limit).

[0084] The above steps S201 to S206, by uniformly obtaining authorization policy configuration and accurately locating the target business deployment unit based on the service name, combined with the dynamic injection of the access proxy component and the standardized push of the native access control policy, realize the centralized and standardized management of the authorization policy, and avoid the problem of inconsistent standards and broken cross-service authorization verification chain caused by the independent implementation of the authorization mechanism by each business department; by using the access proxy component to initiate verification requests based on the native policy, the control plane parses the request and associates the real-time indicator data, and combines the indicator restriction expression with the authorization response generation result mechanism, fine-grained authorization control based on dynamic indicators is realized, and the access proxy component exists synchronously with the drift of the business deployment unit, which ensures the continuity and effectiveness of authorization during dynamic expansion and contraction or container drift in the cloud native environment, and finally achieves a unified, dynamic, and fine-grained software authorization control effect that takes into account the security of private deployment and the flexibility of cloud native, and solves the problem that authorization control is complex to manage and prone to control failure in large-scale distributed systems of cloud native microservice architecture.

[0085] In some embodiments, the method of obtaining the authorization policy configuration includes online acquisition and offline acquisition;

[0086] When the method for obtaining the authorization policy configuration is online acquisition, the authorization policy configuration is obtained from the unified authorization management platform by calling a preset interface of the unified authorization management platform;

[0087] When the method for obtaining the authorization policy configuration is offline acquisition, the preset authorization file is imported into the preset indicator authentication service to obtain the authorization policy configuration.

[0088] Specifically, the method of obtaining authorization policy configuration flexibly covers both online and offline acquisition modes to adapt to the authorization management needs in different scenarios. Among them, when adopting the online acquisition method, the entire process uses the unified authorization management platform as the core data source. The indicator authentication service directly obtains the configured authorization policy configuration from the platform's database by calling the platform's pre-set interface (such as a standardized interface specifically for policy acquisition); this configuration information is entered and stored by the user on the unified authorization management platform through operations such as creating forms. It contains detailed content such as the policy name, description, rule items, effective time, associated accounts and service names, etc., to ensure that the indicator authentication service can synchronize the latest authorization policies in real time. When the network conditions do not meet the requirements for the indicator authentication service to call the authorization policy acquisition interface opened by the unified authorization management platform, an offline acquisition method can be used. The process revolves around the preset authorization file. First, the configured authorization policy is exported from the unified authorization management platform as an authorization file in a specific format. Then, the authorization file is imported into the preset indicator authentication service through tools such as scaffolding. The indicator authentication service loads and parses the imported authorization file, and extracts the complete authorization policy configuration information, including the restrictions, effective time, and associated services of each rule. This ensures that the authorization policy can be accurately acquired and applied even when it is unable to connect to the unified authorization management platform online.

[0089] In the above steps, by obtaining the authorization policy configuration online, the indicator authentication service can call the interface of the unified authorization management platform in real time to obtain the latest configuration, ensuring that the authorization policy can be dynamically synchronized with the update of the platform configuration, meeting the system's requirements for real-time and consistency of the authorization policy when the network is unobstructed, and avoiding the problem of policy lag; and the offline acquisition method imports the authorization file into the indicator authentication service, which can ensure the normal loading and application of the authorization policy in scenarios where network conditions are limited or the unified authorization management platform cannot be connected. The combination of the two methods not only realizes the flexibility and adaptability of authorization policy management, but also ensures the stability and reliability of authorization control in different network environments, effectively supports the implementation of the unified authorization management model, and provides a basic guarantee for solving the problem of authorization policy fragmentation.

[0090] In some embodiments, determining a target service deployment unit from a plurality of service deployment units in the data plane based on the service name, and injecting a preset access proxy component into the target service deployment unit in the data plane includes:

[0091] Based on the service name, determine a target business deployment unit from the multiple business deployment units, and set a component injection mark of the target business deployment unit through a preset service grid management and control component;

[0092] Based on the component injection tag, the access proxy component is injected into the target business deployment unit.

[0093] Specifically, first, using the service name as the key identifier, the target business deployment unit corresponding to the service name is accurately located from a large number of business deployment units (i.e., business PODs) developed and deployed in the K8S cluster by multiple departments in the data plane; then, with the help of the preset service mesh management component (such as Istiod), the configuration of the target business deployment unit is adjusted, and a specific component injection tag is set (such as adding the key-value pair sidecar.istio.io / inject: "true") to clearly indicate that an access proxy component needs to be injected into the target business deployment unit; then, based on this component injection tag, the corresponding injection mechanism is triggered to automatically inject the access proxy component (such as the Envoy Sidecar container) into the target business deployment unit, so that the access proxy component can work together with the business container in the target business deployment unit, thereby realizing the interception and management of the external request traffic processed by the target business deployment unit.

[0094] Through the above steps, the target business deployment unit is first accurately located based on the service name, ensuring the targeted and accurate injection of the access proxy component and avoiding interference with irrelevant business units. Secondly, with the help of the preset service grid control component, the component injection tag is set and the injection is completed, realizing the automation and standardization of the access proxy component injection process. No manual operation is required by the business department, which reduces the errors caused by human intervention. At the same time, the injection mechanism is unified and the problem of fragmented authorization policies is solved. In addition, this on-demand injection method enables the access proxy component to be tightly bound to the target business deployment unit. Even if the business deployment unit drifts (such as Pod restart or migration), the access proxy component can also follow synchronously, ensuring the continuity and effectiveness of authorization control in dynamic resource scenarios, and providing a stable and reliable basic support for subsequent fine-grained authorization control based on dynamic indicator data.

[0095] In some embodiments, injecting the access proxy component into the service deployment unit based on the component injection mark includes:

[0096] When the component injection flag is set, the access proxy component is injected into the service deployment unit.

[0097] Specifically, when the component injection mark (that is, the key-value pair sidecar.istio.io / inject: "true" set on the business deployment unit) is in the set state, the preset access proxy component (such as the Envoy Sidecar container) is automatically injected into the corresponding business deployment unit (business Pod); this set state clearly indicates that the business deployment unit needs to access the access proxy component to achieve traffic interception and authorization control. After the injection is completed, the access proxy component will work together with the business deployment unit within the business deployment unit, and can intercept external request traffic in real time, and verify and process the request according to the subsequent authorization policy configuration.

[0098] Through the above steps, the injection of access proxy components is conditional and automated, which not only ensures that business deployment units that require authorization control can accurately access the access proxy to intercept traffic, but also avoids resource occupation or interference for units that do not require authorization control. At the same time, it ensures the standardization of the injection process, avoids the confusion caused by independent operations of various business departments, lays the foundation for the subsequent unified authorization policy execution, and effectively supports the consistency and reliability of authorization control in a dynamic resource environment.

[0099] In some embodiments, generating an authorization result based on real-time indicator data, an indicator restriction expression, and an authorization response corresponding to the indicator restriction expression includes:

[0100] Bring the real-time indicator data into the indicator restriction expression for calculation to obtain the calculation result;

[0101] Generates an authorization result based on the calculation result, indicator restriction expression, and authorization response.

[0102] Specifically, after receiving the external data verification authorization request (ExtAuthz request) from the access proxy component, the indicator authentication service first obtains the request indicator name, request service name and request rule name associated with the intercepted request through the request information, and then queries the indicator storage system (Prometheus) based on the request indicator name and request service name to obtain the corresponding real-time indicator data (such as the number of device connections, QPS value, etc.), and then substitutes these real-time indicator data into the indicator restriction expression preset in the policy rule (for example, "sum(probe_target_metric{metric='device_num'})<=10") for calculation to obtain the specific calculation result; then, combined with the logical relationship between the calculation result and the indicator restriction expression (such as whether the conditions in the expression are met), and the authorization response corresponding to the indicator restriction expression (such as "allow" or "reject"), the corresponding authorization result is finally determined and returned.

[0103] Through the above steps, first, real-time indicator data (such as the number of device connections, QPS value, etc.) is substituted into the indicator restriction expression for calculation, achieving quantitative matching between dynamic indicators and preset rules, ensuring that authorization judgments are based on real-time business status rather than static configuration; second, the authorization result is generated by combining the calculation results, the logical relationship between the indicator restriction expression, and the corresponding authorization response (such as allow or deny), so that authorization control can accurately respond to dynamic changes in the business. For example, when the number of device connections exceeds the threshold set by the restriction expression, a deny response can be automatically triggered, while requests within the threshold range are allowed to pass. This mechanism not only meets the needs of multi-dimensional and fine-grained authorization control in large-scale ICT privatization deployment, but also solves the problem of insufficient adaptability caused by static binding in traditional authorization methods through the dynamic association of real-time indicators and rules. At the same time, it ensures the consistency and accuracy of authorization judgments, providing flexible and reliable technical support for the authorization management and control of distributed systems.

[0104] In some embodiments, the authorization response includes permission or denial; generating an authorization result based on the calculation result, the indicator restriction expression, and the authorization response includes:

[0105] If the authorization response is "allow", if the calculation result meets the conditions of the indicator restriction expression, it will be allowed as the authorization result;

[0106] If the authorization response is "allow", and the calculation result does not meet the conditions of the indicator restriction expression, the authorization result will be rejected;

[0107] If the authorization response is a rejection, if the calculation result meets the conditions of the indicator restriction expression, the rejection will be regarded as the authorization result;

[0108] In the case where the authorization response is denied, if the calculation result does not meet the conditions of the indicator restriction expression, it will be allowed as the authorization result.

[0109] Specifically, when the authorization response is preset to allow, if the calculation result obtained after substituting the real-time indicator data into the indicator restriction expression meets the conditions set by the expression (for example, the number of device connections does not exceed the limit value, the QPS is within the threshold range, etc.), the final generated authorization result is allow; if the authorization response is preset to allow, the calculation result does not meet the conditions of the indicator restriction expression (such as the number of device connections exceeds the upper limit, the QPS exceeds the threshold, etc.), the authorization result is adjusted to reject; when the authorization response is preset to reject, if the calculation result meets the conditions of the indicator restriction expression, the authorization result remains reject; if the authorization response is preset to reject, but the calculation result does not meet the conditions of the indicator restriction expression, the authorization result is reversed to allow.

[0110] Through the above steps, the multi-scenario judgment logic that combines the preset status of the authorization response with the real-time indicator data calculation results and indicator restriction expression conditions not only ensures that the authorization control can strictly follow the preset policy tendencies, but also can adjust the authorization results in real time according to dynamically changing business indicators (such as the number of device connections, QPS, etc.), realizing fine-grained and highly adaptable authorization management and control, and effectively solving the problem that static control in traditional authorization methods is difficult to cope with the dynamic changes of large-scale distributed systems. At the same time, it ensures the accuracy and flexibility of authorization judgment, and meets the complex needs of software authorization control in large-scale ICT privatization deployment projects.

[0111] This embodiment provides another software authorization control method. Figure 3 This is a flowchart of another software authorization control method according to an embodiment of the present application, which is applied to the data plane, such as Figure 3 As shown, the process includes the following steps:

[0112] Step S301, obtain the access proxy component injected by the control plane, and install the access proxy component to the target business deployment unit determined by the control plane based on the service name from multiple business deployment units of the data plane; the service name is determined by the control plane based on the obtained authorization policy configuration.

[0113] Specifically, the data plane first obtains the access proxy component (such as the Envoy Sidecar container) injected by the control plane. This component is used to intercept business traffic and perform authorization checks; then, the data plane installs the access proxy component to a specific target business deployment unit (i.e., business POD), and this target business deployment unit is accurately determined by the control plane from multiple business deployment units of the data plane based on the service name; among them, the service name is obtained by the control plane from the authorization policy configuration by online calling the unified authorization management platform interface or offline importing the authorization file, and then parsed from the configuration content. Through this process, the access proxy component is accurately bound to the target business deployment unit.

[0114] Step S302, obtain the native access control policy sent by the control plane; the native access control policy is obtained by the indicator authentication service of the control plane after converting the preset authorization policy configuration into a format; the native access control policy includes the request method, request path and indicator name.

[0115] Specifically, the access proxy component of the data plane will obtain the native access control policy sent by the control plane. The process of forming this native access control policy is: the indicator authentication service of the control plane first obtains the preset authorization policy configuration (including policy name, description, rule items, effective time, associated account, role, service name, etc.) by calling the unified authorization management platform interface online or importing the authorization file offline. The rule items involve request method, request path, associated indicator name, indicator restriction expression and authorization response, etc., and then converts these authorization policy configurations into native access control policies (i.e., AuthorizationPolicy). The converted native access control policy specifically includes the request method related to authorization verification (such as POST, GET, etc.), request path (such as / api / camera, etc.) and associated indicator name (such as device_num corresponding to the number of device connections, etc.), so that the access proxy component (such as Envoy Sidecar) can accurately intercept and match the corresponding requests based on this information.

[0116] Step S303: Load the native access control policy into the access proxy component.

[0117] Specifically, the access proxy component automatically completes hot loading of native access control policy configuration, making the new native access control policy effective immediately without restarting the component, thereby ensuring that the access proxy component can accurately identify external requests based on the loaded policy.

[0118] Step S304, obtain external data to the access proxy component; when the external data matches the request method and request path, initiate an external data verification authorization request to the indicator authentication service of the control plane; the external data verification authorization request includes the request indicator name, request service name and request rule name.

[0119] Specifically, when external data (such as HTTP requests) initiated by external clients reaches the data plane, it will first be intercepted by the access proxy component (such as the Envoy Sidecar container) deployed in the target business deployment unit; the access proxy component will parse the obtained external data, extract the request method (such as POST, GET, etc.) and request path (such as / api / camera, etc.), and match it with the request method and request path contained in the loaded native access control policy (AuthorizationPolicy); if the request method and request path of the external data match the corresponding information in the policy, the access proxy component will initiate an external data verification authorization request to the indicator authentication service of the control plane. The request includes the request indicator name extracted from the external data (such as device_num corresponding to the number of connected devices), the request service name (such as videocloud-device), and the request rule name (such as rule identifiers such as "the number of connected devices cannot exceed 10"), so that the indicator authentication service can query real-time indicator data based on this information and perform authorization verification.

[0120] Step S305 , periodically obtaining multiple indicator data of multiple business deployment units, and aggregating the multiple indicator data and writing them into a preset indicator storage system.

[0121] Specifically, the indicator collection component of the data plane (such as Probe Pod) will periodically call the different indicator data query interfaces exposed by multiple business deployment units (business PODs) in an active pull mode. These indicator data include multi-dimensional information such as the number of device connections, QPS (query rate per second), and the number of GPU cannons, corresponding to the real-time status of each business POD during operation; after obtaining these scattered indicator data, the indicator collection component will centrally aggregate and process them, and then call the interface " / api / v1 / write" of the preset indicator storage system (such as Prometheus) to remotely write the aggregated multiple indicator data directly into the indicator storage system, realizing unified storage and management of various dynamic indicator data, and providing a reliable data source for the subsequent control plane indicator authentication service to query real-time indicator data during authorization verification.

[0122] Step S306 , in response to the query request of the indicator authentication service, query the real-time indicator data in the indicator storage system and send it to the indicator authentication service; the real-time indicator data corresponds to the requested indicator name and the requested service name.

[0123] Specifically, when the indicator authentication service of the control plane receives an external data verification authorization request from the access proxy component (such as EnvoySidecar), it will initiate a query request to the preset indicator storage system (such as Prometheus) for the request indicator name (such as device_num corresponding to the number of device connections) and the request service name (such as the associated business service name videocloud-device) contained in the request; in response to the query request, the indicator storage system will accurately filter out the real-time indicator data that matches the request indicator name and the request service name (such as the current number of device connections and QPS value of a specific service) from the various indicator data stored in it that are regularly aggregated and written by the indicator collection component (Probe Pod), and send these real-time indicator data feedback to the indicator authentication service, providing accurate dynamic data support for the indicator authentication service to subsequently substitute the indicator restriction expression for calculation and generate authorization results.

[0124] Step S307: Obtain the authorization result sent by the indicator authentication service; the authorization result is obtained by the indicator authentication service based on the real-time indicator data and the request rule name.

[0125] Specifically, the access proxy component (such as the Envoy Sidecar container) will obtain the authorization result sent by the indicator authentication service of the control plane. The process of generating this authorization result is: after receiving the external data verification authorization request initiated by the access proxy component, the indicator authentication service first extracts the request rule name from the request, and at the same time queries the corresponding real-time indicator data (such as the number of connected devices, QPS value, etc.) from the indicator storage system (such as Prometheus) based on the request indicator name and request service name in the request. Then, according to the request rule name, it obtains the preset indicator restriction expression and the corresponding authorization response, and then generates the authorization result based on the real-time indicator data, indicator restriction expression and authorization response, and finally sends the authorization result to the access proxy component.

[0126] Step S308: When the authorization result is rejected, the external data is processed according to the indicator name and the preset exception handling strategy.

[0127] Specifically, when the authorization result is denied, the access proxy component will call the preset exception handling strategy to perform targeted processing on the external data based on the indicator name associated with the external data (such as QPS, number of device connections, etc.); these exception handling strategies are pre-set when configuring the authorization strategy on the unified authorization management platform. For example, when the indicator name is QPS and its corresponding real-time indicator data exceeds the threshold set by the restriction expression, resulting in a denied authorization result, the system will perform graceful degradation processing, such as limiting the response rate of some non-core functions to ensure the stable operation of core functions. Through this differentiated exception handling method bound to specific indicator names and scenarios, while ensuring the effectiveness of authorization control, it minimizes the impact on business continuity and improves the system's fault tolerance and user experience under restricted authorization conditions.

[0128] Through steps S301 to S308, the data plane achieves precise binding with the target business deployment unit by acquiring and installing the access proxy component injected by the control plane, ensuring that authorization control can be targeted to specific businesses. After loading the native access control policy, the access proxy component can accurately intercept external data and initiate authorization requests based on information such as the request method and path. Combined with multi-dimensional indicator data that is regularly aggregated and written to the indicator storage system, it provides a dynamic basis for the control plane's real-time authorization verification. The indicator storage system responds to queries and returns corresponding real-time data, enabling the indicator authentication service to generate accurate authorization results. When the authorization result is rejected, the external data is processed based on the indicator name and preset exception policies (such as graceful degradation when the QPS limit is exceeded). This series of processes not only solves the problems of fragmentation and failure of traditional authorization policies and dynamic resource binding, but also implements fine-grained authorization control based on real-time indicators. At the same time, it ensures the continuity and stability of services under restricted authorization conditions, meets the security and flexibility requirements for software authorization in large-scale ICT private deployments, and solves the problem of complex management and control failure in large-scale distributed systems of cloud-native microservices architecture.

[0129] In some embodiments, the authorization result is obtained by the indicator authentication service based on the request rule name, determining the indicator restriction expression and the authorization response corresponding to the indicator restriction expression; based on the real-time indicator data, indicator restriction expression and authorization response.

[0130] Specifically, the authorization result generation process is as follows: after receiving the external data verification authorization request, the indicator authentication service first matches and determines the corresponding indicator restriction expression (such as "sum(probe_target_metric{metric='device_num'})<=10") and the authorization response corresponding to the indicator restriction expression (such as "allow" or "reject") from the preset authorization policy configuration according to the request rule name contained in the request; then, the indicator authentication service substitutes the real-time indicator data corresponding to the requested indicator name and the requested service name (such as the current number of device connections, QPS value, etc.) queried from the indicator storage system into the determined indicator restriction expression for calculation; finally, the final authorization result is generated by combining the logical relationship between the calculation result and the indicator restriction expression (that is, whether the conditions in the expression are met) and the preset authorization response.

[0131] Through the above embodiment, the indicator authentication service accurately determines the corresponding indicator restriction expression and authorization response based on the request rule name, and generates the authorization result in combination with the real-time indicator data, realizing the deep association between the authorization judgment and the dynamic business indicators. It not only ensures that the authorization control can strictly follow the preset policy rules, but also can flexibly adjust the authorization results according to the real-time business status (such as the number of device access, QPS, etc.), meeting the needs of multi-dimensional and fine-grained authorization control in large-scale ICT privatization deployment; at the same time, this mechanism of binding rules, indicators and response logic avoids the limitations of static configuration in traditional authorization methods, solves the problems of fragmentation of authorization policies and coarse control granularity, ensures the accuracy and dynamic adaptability of authorization judgment, and provides reliable support for the authorization management and control of distributed systems.

[0132] Figure 4 This is a flow chart of external data authorization control according to an embodiment of the present application, such as Figure 4 As shown, the process includes the following steps:

[0133] Step S401: Initiate an HTTP request. The external client sends external data, such as an HTTP request, to the business service, attempting to interact with the business service.

[0134] Step S402: Execute the interception logic. The access proxy component intercepts the HTTP request sent by the external client. If the request matches the preset access control policy, it initiates a verification authorization request to the indicator authentication service. The indicator authentication service queries the indicator storage system for the real-time indicator data corresponding to the verification authorization request. After receiving the real-time data, the indicator authentication service verifies it according to the preset authorization policy rules (such as whether the indicator data is within the permitted range), determines whether to allow or deny the request, and then returns the result to the access proxy component.

[0135] Step S403: Forwarding the legitimate request. When the access proxy component receives the "allow" result returned by the indicator authentication service, it forwards the HTTP request that was previously intercepted and passed the dynamic check to the corresponding business service, allowing the business service to receive and process the request.

[0136] Step S404: Returning a response: After receiving the request forwarded by the access proxy component, the business service processes it according to its own business logic, such as executing business operations, and generates corresponding response data after processing is completed, and then returns the response to the access proxy component.

[0137] Step S405: Returning an HTTP response. After the access proxy component obtains the response content returned by the business service, it passes it to the external client that initiated the request, allowing the client to receive the result processed by the business service, thus completing the entire interactive process from request initiation to response reception.

[0138] Figure 5 is a system architecture diagram of a software authorization control method according to an embodiment of the present application, such as Figure 5 As shown, the process includes the following steps:

[0139] Step S501: Obtain authorization policy configuration. The indicator authentication service obtains authorization policy configuration in two ways: offline and online.

[0140] In step S502, the metric authentication service notifies the service mesh control component. After obtaining the authorization policy configuration, the metric authentication service locates the business pod based on the service name and notifies the service mesh control component, Istiod, to modify the business pod's label, adding the key-value pair sidecar.istio.io / inject: "true" to trigger the injection of the Envoy sidecar container. Furthermore, the metric authentication service converts the authorization configuration content (such as the service name, request path, request method, and metric name) into Istio's native access control policy, AuthorizationPolicy, and notifies Istiod to push the configuration changes to the relevant Envoy sidecar container via xDS (gRPC streaming). Envoy automatically performs a hot reload of the configuration, and the new policy takes effect immediately, beginning to allow / deny requests based on the rules.

[0141] Step S503: The access proxy component intercepts external data. When external data attempts to access the service container within the service deployment unit, the access proxy component deployed in the service deployment unit intercepts the external data to prepare for subsequent authorization verification and other processes, ensuring that only requests that comply with the authorization policy can continue to access the service container.

[0142] In step S504, the Metrics Collection Component actively pulls metrics and reports them to the Metrics Storage System. The Probe Pod, a Metrics Collection Component, centrally and periodically calls the different metrics data query interfaces provided by different business pods to aggregate metrics data. Finally, the Probe Pod writes the data remotely to Prometheus by calling the Prometheus interface " / api / v1 / write."

[0143] In step S505, the access proxy component initiates an external data verification authorization request to the Metrics Authentication Service. When external data requests access the business pod, the access proxy component intercepts all traffic from the business container. If the access proxy component matches the request path, request method, and other information in the native access control policy AuthorizationPolicy, it initiates an external data verification authorization request (ExtAuthz request) to the Metrics Authentication Service based on the EnvoyFilter configured in Istio and waits for the authorization result. All other requests are directly released. (EnvoyFilter is an Istio configuration. Istio itself provides an access control proxy that can initiate ExtAuthz requests based on the Metrics Authentication Service address configured by the EnvoyFilter.)

[0144] In step S506, the indicator authentication service queries the indicator storage system for indicator data. Upon receiving the verification authorization request from the access proxy component, the indicator authentication service initiates a query operation with the indicator storage system to obtain the indicator data required for authorization (for example, to determine whether the current number of connected devices exceeds the limit, it is necessary to query the device access count indicator stored in the indicator storage system). The query retrieves the corresponding indicator information from the indicator storage system and stores the obtained data in the cache database.

[0145] In step S507, the indicator authentication service returns the authorization result. The indicator authentication service combines the real-time indicator data retrieved from the indicator storage system with the authorization policy rules to make an authorization decision. It then returns the authorization result (allow or deny) to the access proxy component, which then decides whether to release the external data to the business container based on the result.

[0146] Through the above steps, first, the software authorization control logic is decentralized, addressing the fragmentation of authorization policies. Based on a core architecture of a control plane and data plane, authorization rule definitions on the control plane are deeply integrated with the service mesh's AuthorizationPolicy, enabling centralized declarative authorization management and configuration through Kubernetes Custom Resource Definitions (CRDs). On the data plane, access control proxies bypass external access control, eliminating the need for business departments to implement their own software authorization logic. Secondly, the authorization control logic is dynamically injected to avoid invalid bindings between dynamic resources and authorizations. After the access control proxies are injected into business pods on demand, even if the business pods migrate, the access control proxies will migrate synchronously, maintaining the binding relationship until the relevant authorization policy is deleted. Thirdly, refined authorization control is achieved by incorporating a closed-loop feedback mechanism from control theory to dynamically limit authorization limits based on real-time business metrics (such as API request rates). The flexible combination of policy-associated rules and rule-associated metrics enables fine-grained control.

[0147] The specific implementation process of this embodiment is as follows. The following steps are used to illustrate how to control the "number of device accesses". The control operation steps for other indicators are similar.

[0148] The first step is to initialize and deploy the software authorization system. First, install Istio. Use the official istioctl tool to complete the deployment by running istioctl install --set profile=default -y in the Kubernetes cluster. Next, prepare the deployment manifest files for the unified authorization management platform, authmesh-manager; the metric authentication service, authz-server; and the metric collection component, authmesh-probe. Complete the deployment using kubectl apply -f. Finally, modify the Istio extensionProviders configuration to specify the metric authentication service, authz-server.

[0149] The second step is to adjust the configuration of the metrics collection component. Modify the metrics collection component configuration file, config.yaml, and configure the Kubernetes metrics discovery mode to "pod," the metric name to "device_num," the metric interface path to " / pu / count," and the associated Pod label to "app=videocloud-device." This step involves configuring the Probe Pod; the same business service can have multiple pods, and the associated labels are used to filter out related business service instances.

[0150] Step 3: Configure the authorization policy. Log in to the unified authorization management platform, create a new rule on the policy rule page, configure the rule name as "The number of device accesses shall not exceed 10", the resource (request path) as " / camera", the operation (request method) as "POST", the metric limit expression (matching rule) as "sum(probe_target_metric{metric='device_num'})<=10", and the authorization response as "Allowed". Create a new policy on the authorization policy page, configure the policy name as "Limit on the number of camera device accesses", the associated service (service name) as "videocloud-device", the effective start and end times as one month, and the associated rule as "The number of device accesses shall not exceed 10". When the network condition does not meet the metric authentication service to call the authorization policy acquisition interface " / openapi / v1 / policys" opened by the unified authorization management platform, you can click "Export Authorization Policy" to obtain the offline authorization file.lnc, which is required for offline authorization.

[0151] Step 4: (Optional) Offline authorization. Modify the configuration file config.yaml of the metric authentication service "authz-server", configure the authorization mode as "offline", the authorization file path as " / conf / offline authorization file.lnc", and restart the service to load all the authorization policies included in the offline authorization file.

[0152] Step 5: Verify the authorization control effect. The initial device count is 0. Increase the number of device accesses by executing "curl -I -X POST http: / / <IP of videocloud-devicede service>:<IP of videocloud-devicede service> / camera", and the first ten responses are normal. When the eleventh execution is made, the response is rejected. This command is the interface for adding the number of devices; the command is sent to the business service.

[0153] Thus, the implementation of controlling the "number of device accesses" is completed.

[0154] This embodiment also provides a software authorization control device, which is applied to the control plane. This device is used to implement the above embodiments and preferred implementation manners, and those that have been described will not be repeated. As used hereinafter, terms such as "module", "unit", "sub-unit", etc. may be a combination of software and / or hardware that can achieve a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0155] Figure 6 is a structural block diagram of a software authorization control device according to an embodiment of the present application, as Figure 6As shown, the device includes:

[0156] The authorization policy acquisition module 61 is used to obtain the authorization policy configuration; the authorization policy configuration includes the service name;

[0157] The access proxy injection and policy push module 62 is used to determine the target business deployment unit from multiple business deployment units in the data plane based on the service name, and inject the preset access proxy component into the target business deployment unit in the data plane; convert the authorization policy configuration format to obtain the native access control policy, and push the native access control policy to the access proxy component in the target business deployment unit;

[0158] The verification request parsing module 63 is used to respond to the external data verification authorization request sent by the data plane and parse the external data verification authorization request to obtain the request indicator name, request service name, and request rule name; the external data verification authorization request is sent by the access proxy component based on the native access control policy;

[0159] The real-time indicator data acquisition module 64 is used to obtain the real-time indicator data sent by the indicator storage system of the data plane; the real-time indicator data corresponds to the requested indicator name and the requested service name;

[0160] The authorization rule determination module 65 is used to determine the indicator restriction expression and the authorization response corresponding to the indicator restriction expression based on the request rule name;

[0161] The authorization result generation module 66 is used to generate an authorization result based on the real-time indicator data, the indicator restriction expression and the authorization response.

[0162] It should be noted that the above modules can be functional modules or program modules, and can be implemented by software or hardware. For modules implemented by hardware, the above modules can be located in the same processor; or the above modules can be located in different processors in any combination. For specific examples in this embodiment, reference can be made to the examples described in the above embodiment and optional implementations, and will not be repeated in this embodiment.

[0163] In addition, in conjunction with the software authorization control method in the above embodiments, the present application embodiment can provide a storage medium for implementation. The storage medium stores a computer program; when the computer program is executed by a processor, any one of the software authorization control methods in the above embodiments is implemented.

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

[0165] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. 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 above-mentioned embodiments. In particular, any reference to memory, database, or other media used in the embodiments provided in this application can include at least one of non-volatile 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 various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The databases involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processors involved in the various embodiments provided herein may be, but are not limited to, general-purpose processors, central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), programmable logic devices (PLDs), data processing logic devices based on quantum computing, and the like.

[0166] Those skilled in the art should understand that the various technical features of the above-described embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the various technical features in the above-described 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 specification.

[0167] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the spirit of the present application, all of which fall within the scope of protection of the present application. Therefore, the scope of protection of the present patent application shall be determined by the appended claims.

Claims

1. A software authorization control method, characterized in that: Applied to the control plane, the method includes: Obtaining authorization policy configuration; the authorization policy configuration includes a service name; Based on the service name, a target business deployment unit is determined from multiple business deployment units in the data plane, and a preset access proxy component is injected into the target business deployment unit in the data plane; the authorization policy configuration is formatted to obtain a native access control policy, and the native access control policy is pushed to the access proxy component in the target business deployment unit; In response to the external data verification authorization request sent by the data plane, the external data verification authorization request is parsed to obtain a request indicator name, a request service name, and a request rule name; the external data verification authorization request is sent by the access proxy component based on the native access control policy; Acquire real-time indicator data sent by the indicator storage system of the data plane; the real-time indicator data corresponds to the requested indicator name and the requested service name; Determine, based on the request rule name, an indicator restriction expression and an authorization response corresponding to the indicator restriction expression; An authorization result is generated based on the real-time indicator data, the indicator restriction expression and the authorization response.

2. The software authorization control method according to claim 1, characterized in that: The method of obtaining the authorization policy configuration includes online acquisition and offline acquisition; When the method for obtaining the authorization policy configuration is online acquisition, the authorization policy configuration is obtained from the unified authorization management platform by calling a preset interface of the unified authorization management platform; When the method for obtaining the authorization policy configuration is offline acquisition, the preset authorization file is imported into the preset indicator authentication service to obtain the authorization policy configuration.

3. The software authorization control method according to claim 1, characterized in that: The determining, based on the service name, a target service deployment unit from a plurality of service deployment units in the data plane, and injecting a preset access proxy component into the target service deployment unit in the data plane includes: Based on the service name, determining the target business deployment unit from the multiple business deployment units, and setting a component injection flag of the target business deployment unit through a preset service grid management and control component; Based on the component injection mark, the access proxy component is injected into the target service deployment unit.

4. The software authorization control method according to claim 3, characterized in that: The injecting the access proxy component into the service deployment unit based on the component injection mark includes: In a case where the component injection flag is in a set state, the access proxy component is injected into the service deployment unit.

5. The software authorization control method according to claim 1, characterized in that: The generating of the authorization result based on the real-time indicator data, the indicator restriction expression, and the authorization response corresponding to the indicator restriction expression includes: Bringing the real-time indicator data into the indicator restriction expression for calculation to obtain a calculation result; The authorization result is generated based on the calculation result, the indicator restriction expression and the authorization response.

6. The software authorization control method according to claim 5, characterized in that: The authorization response includes permission or rejection; generating the authorization result based on the calculation result, the indicator restriction expression and the authorization response includes: In the case where the authorization response is allow, if the calculation result meets the conditions of the indicator restriction expression, it will be allowed as the authorization result; In the case where the authorization response is allow, if the calculation result does not meet the conditions of the indicator restriction expression, rejection is used as the authorization result; In the case where the authorization response is rejection, if the calculation result meets the conditions of the indicator restriction expression, rejection is taken as the authorization result; In the case where the authorization response is a rejection, if the calculation result does not meet the conditions of the indicator restriction expression, it will be allowed as the authorization result.

7. A software authorization control method, characterized in that: Applied to the data plane, the method includes: Obtaining an access proxy component injected by the control plane, and installing the access proxy component into a target service deployment unit determined by the control plane from a plurality of service deployment units of the data plane based on a service name; the service name is determined by the control plane based on the obtained authorization policy configuration; Obtain the native access control policy sent by the control plane; the native access control policy is obtained by formatting the preset authorization policy configuration by the indicator authentication service of the control plane; the native access control policy includes the request method, request path and indicator name; Loading the native access control policy into the access proxy component; Obtain external data from the access proxy component; if the external data matches the request method and the request path, initiate an external data verification authorization request to the indicator authentication service of the control plane; the external data verification authorization request includes the request indicator name, the request service name, and the request rule name; Regularly obtain multiple indicator data of the multiple business deployment units, and write the multiple indicator data into a preset indicator storage system after aggregating them; In response to a query request from the indicator authentication service, query the indicator storage system for real-time indicator data and send the real-time indicator data to the indicator authentication service; the real-time indicator data corresponds to the requested indicator name and the requested service name; Obtaining an authorization result sent by the indicator authentication service; the authorization result is obtained by the indicator authentication service based on the real-time indicator data and the request rule name; When the authorization result is rejection, the external data is processed according to the indicator name and the preset exception handling strategy.

8. The software authorization control method according to claim 7, characterized in that: The authorization result is determined by the indicator authentication service based on the request rule name, and the indicator restriction expression and the authorization response corresponding to the indicator restriction expression; Obtained based on the real-time indicator data, the indicator restriction expression and the authorization response.

9. A software authorization control device, characterized in that: Applied to a control plane, the device includes: An authorization policy acquisition module is used to obtain an authorization policy configuration; the authorization policy configuration includes a service name; An access proxy injection and policy push module is used to determine a target business deployment unit from multiple business deployment units in the data plane based on the service name, and inject a preset access proxy component into the target business deployment unit in the data plane; convert the format of the authorization policy configuration to obtain a native access control policy, and push the native access control policy to the access proxy component in the target business deployment unit; a verification request parsing module, configured to respond to an external data verification authorization request sent by the data plane, parse the external data verification authorization request, and obtain a request indicator name, a request service name, and a request rule name; the external data verification authorization request is sent by the access proxy component based on the native access control policy; A real-time indicator data acquisition module, configured to acquire real-time indicator data sent by the indicator storage system of the data plane; the real-time indicator data corresponds to the request indicator name and the request service name; An authorization rule determination module, configured to determine an indicator restriction expression and an authorization response corresponding to the indicator restriction expression based on the request rule name; The authorization result generation module is used to generate an authorization result based on the real-time indicator data, the indicator restriction expression and the authorization response.

10. A storage medium, characterized in that: The storage medium stores a computer program, wherein the computer program is configured to execute the software authorization control method according to any one of claims 1 to 8 when running.

Images