Software authorization control method, device and storage medium

Abstract

The application relates to a software authorization control method and device and a storage medium, wherein the software authorization control method comprises the following steps: acquiring an authorization policy configuration comprising a service name; determining a target business deployment unit based on the service name, and injecting an 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; in response to an external data verification authorization request and analysis, obtaining 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 limit expression and an authorization response corresponding to the index limit expression based on the request rule name; and generating an authorization result based on the real-time index data, the index limit expression and the authorization response. Through the application, the problem that authorization control management is complex and control failure is prone to occur is solved.

Description

Technical Field

[0001] This application relates to the field of computer application software license management technology, and in particular to software license control methods, devices and storage media. Background Technology

[0002] In the fields of computer application software licensing management and cloud-native technologies, software license control is a crucial link in ensuring compliant software use and balancing developer rights with user needs. Common software license control methods mainly include hardware binding (such as MAC address and CPU serial number binding), online activation verification, and dongle or license file verification. These methods can play a certain role in single-machine or fixed cluster environments. However, in large-scale private deployment projects in the ICT field, modern systems generally adopt cloud-native microservice architectures, consisting of hundreds or even thousands of microservices developed collaboratively by multiple departments (for example, an ICT project deployed hundreds of business PODs in a Kubernetes cluster, including access aggregation, view storage, and baseline applications, developed by different business departments). While this architecture improves system flexibility and scalability, it also brings many challenges to software license control. Related technologies are difficult to adapt to the needs of large-scale distributed systems, resulting in complex management of license control in large-scale distributed systems with cloud-native microservice architectures, and the problem of control failure is prone to occur.

[0003] Currently, no effective solution has been proposed to address the issue of complex management and susceptibility to control failures in large-scale distributed systems with cloud-native microservice architectures. Summary of the Invention

[0004] This application provides a software authorization control method, apparatus, and storage medium to at least solve the problem in the related art that authorization control is complex to manage and prone to control failure in large-scale distributed systems with cloud-native microservice architecture.

[0005] In a first aspect, embodiments of this application provide a software licensing control method applied to a control plane, the method comprising:

[0006] Obtain the authorization policy configuration; the authorization policy configuration includes the 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 format-converted 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 and authorization request sent by the data plane, the external data verification and authorization request is parsed to obtain the requested metric name, the requested service name, and the requested rule name; the external data verification and authorization request is sent by the access proxy component based on the native access control policy;

[0009] Obtain 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] Based on the request rule name, determine the indicator restriction expression and the corresponding authorization response;

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

[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, the authorization policy configuration is obtained from the unified authorization management platform by calling the interface of the preset unified authorization management platform;

[0014] When the method for obtaining the authorization policy configuration is offline, 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 business deployment unit from multiple business deployment units in the data plane based on the service name, and injecting a preset access proxy component into the target business deployment unit in the data plane includes:

[0016] Based on the service name, the target business deployment unit is determined from the plurality of business deployment units, and the component injection tag of the target business deployment unit is set through a preset service mesh management component;

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

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

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

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

[0021] The real-time indicator data is substituted into the indicator constraint expression for calculation to obtain the 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 allowing or denying; generating the authorization result based on the calculation result, the indicator restriction expression, and the authorization response includes:

[0024] If the authorization response is permitted, and the calculation result meets the conditions of the indicator restriction expression, then it will be allowed as the authorization result.

[0025] If the authorization response is allowed, but the calculation result does not meet the conditions of the indicator restriction expression, it will be rejected as the authorization result.

[0026] If the authorization response is a rejection, and the calculation result meets the conditions of the indicator restriction expression, then rejection will be taken as the authorization result.

[0027] If the authorization response is a rejection, and the calculation result does not meet the conditions of the indicator restriction expression, then it will be allowed as the authorization result.

[0028] Secondly, embodiments of this application provide a software licensing control method applied to the data plane, the method comprising:

[0029] Obtain the access proxy component injected by the control plane, and install the access proxy component into the target business deployment unit determined by the control plane from multiple business deployment units in the data plane based on the 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 the indicator authentication service of the control plane after converting the preset authorization policy configuration into a new format; the native access control policy includes the request method, request path, and indicator name;

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

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

[0033] The system periodically acquires multiple indicator data from the multiple business deployment units, aggregates the multiple indicator data, and writes it into a preset indicator storage system.

[0034] In response to the query request of the indicator authentication service, real-time indicator data is queried in the indicator storage system and sent to the indicator authentication service; the real-time indicator data corresponds to the requested indicator name and the requested service name;

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

[0036] If the authorization result is rejected, 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 determining the indicator restriction expression and the corresponding authorization response based on the request rule name; and based on the real-time indicator data, the indicator restriction expression, and the authorization response.

[0038] Thirdly, embodiments of this application provide a software licensing control device applied to a control plane, the device comprising:

[0039] The authorization policy acquisition module is used to acquire authorization policy configuration; the authorization policy configuration includes the service name;

[0040] The access proxy injection and policy push module 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 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;

[0041] The verification request parsing module is used to respond to the external data verification authorization request sent by the data plane, parse the external data verification authorization request, and 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;

[0042] The real-time indicator data acquisition module is used to 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;

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

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

[0045] Fourthly, embodiments of this application provide a storage medium storing a computer program thereon, which, when executed by a processor, implements the software licensing control method as described in the first and second aspects above.

[0046] Compared to related technologies, the software authorization control method, apparatus, and storage medium provided in this application embodiment are applied to the control plane. The method involves obtaining an authorization policy configuration, including a service name; determining a target business deployment unit from multiple business deployment units in the data plane based on the service name, and injecting a preset access proxy component into the target business deployment unit in the data plane; converting the authorization policy configuration to obtain a native access control policy, and pushing the native access control policy to the access proxy component in the target business deployment unit; parsing an external data verification authorization request sent by the data plane to obtain a requested indicator name, a requested service name, and a requested rule name; the external data verification authorization request is sent by the access proxy component based on the native access control policy; obtaining real-time indicator data sent by the indicator storage system of the data plane; the real-time indicator data corresponding to the requested indicator name and the requested service name; determining an indicator restriction expression and the corresponding authorization response based on the request rule name; and generating an authorization result based on the real-time indicator data, the indicator restriction expression, and the authorization response. This method solves the problem of complex management and easy control failure in large-scale distributed systems with cloud-native microservice architectures.

[0047] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0048] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0049] Figure 1 This is a hardware structure block diagram of a terminal for a software licensing control method according to an embodiment of this application;

[0050] Figure 2 This is a flowchart of a software licensing control method according to an embodiment of this application;

[0051] Figure 3 This is a flowchart of another software licensing control method according to an embodiment of this application;

[0052] Figure 4 This is an external data authorization control flowchart according to an embodiment of this application;

[0053] Figure 5 This is a system architecture diagram of a software licensing control method according to an embodiment of this application;

[0054] Figure 6 This is a structural block diagram of a software licensing control device according to an embodiment of this application. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application. Furthermore, it is understood that although the efforts made in such a development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, modifications to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.

[0056] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0057] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “a,” “an,” “an,” “the,” and similar words used in this application do not indicate quantity limitation and may indicate singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes 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 these processes, methods, products, or devices. The terms “connected,” “linked,” “coupled,” and similar words used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. “Multiple” used in this application means two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. The terms “first,” “second,” “third,” etc., used in this application are merely to distinguish similar objects and do not represent a specific ordering of the objects.

[0058] The method embodiments provided in this example can be executed on a terminal, computer, or similar computing device. Taking running on a terminal as an example, Figure 1 This is a hardware structure block diagram of a terminal according to an embodiment of the software licensing control method of this application. For example... Figure 1 As shown, a terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. Optionally, the terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the terminal described above. For example, the terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0059] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the software licensing control method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the aforementioned method. The memory 104 may include high-speed random access memory and 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 memory remotely located relative to the processor 102, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0060] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0061] Definitions:

[0062] Software licensing refers to the process of clearly defining the scope of a user's rights to use software through legal agreements (such as licenses), including the method, duration, quantity, and restrictions of use. Its core is to control the compliant distribution of products through licensing models (such as subscriptions, perpetual licenses, and pay-as-you-go) and technical means (such as serial numbers, activation codes, and dongles), balancing developer rights and user needs, and preventing piracy and abuse.

[0063] Service Mesh: A dedicated communication infrastructure in a microservice architecture. It intercepts and manages inter-service traffic through sidecar proxies (such as Envoy), enabling non-intrusive traffic control (e.g., canary deployment, load balancing), secure communication (mTLS encryption, RBAC authorization), and observability (metrics, logs, tracing). Its core is divided into a data plane (handling actual traffic) and a control plane (unified configuration policies). Typical tools include Istio and Linkerd, aiming 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 of information processing, storage, transmission and management using computers, networks, communication technologies, etc. 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 framework for designing, developing, and running applications in a cloud computing environment. It aims to fully leverage the elasticity, distributed nature, and automation of the cloud to improve application scalability, reliability, and delivery efficiency. Its core idea is to allow applications to "be born in the cloud 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 crucial link in ensuring compliant software use and balancing developer rights with user needs. Common software licensing control methods mainly 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 field, modern systems typically adopt a cloud-native microservice architecture, consisting of hundreds or even thousands of microservices developed collaboratively by multiple departments. For example, an ICT project deployed 40 business 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 on a Kubernetes cluster, each developed by one of five business departments. While this architecture improves flexibility and scalability, it also brings unprecedented complexity to software licensing control. Current software licensing technologies are mainly designed for single-machine or fixed cluster environments and are difficult to adapt to large-scale distributed systems, mainly due to the following problems:

[0067] (1) Fragmented authorization strategy: Each business department implements the authorization mechanism independently, resulting in inconsistent authorization standards (some use hardware binding, some use license files), broken authorization verification chain when calling across services, and difficulty in monitoring the overall authorization status globally.

[0068] (2) Failure of dynamic resource and authorization binding: Cloud-native applications can automatically scale up and down (such as dynamic addition and removal of Kubernetes Pods), but traditional authorization binding is based on static hardware information (such as MAC address) or a fixed number of nodes, which causes authorization to fail after container migration (Pod restart / migration) or new instances to fail to automatically obtain legal authorization when automatically scaling up, 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 finer granular authorization control, such as the number of devices connected, the upper limit of QPS (queries per second), and the number of GPU cards. Existing technologies are difficult to support such multi-dimensional on-demand dynamic authorization control.

[0070] The software authorization control method in this embodiment mainly involves the data plane and the control plane. The control plane includes the indicator authentication service and the service mesh management component Istiod. It is primarily responsible for distributing authorization policies, handling policy creation, deletion, modification, and querying; querying indicator data and verifying policy validity; compiling authorization policies into an intermediate format and distributing them to the access proxy component Envoy Sidecar via the xDS protocol; and automatically injecting Envoy Sidecars that intercept external requests into business deployment units (business Pods) as needed. The data plane consists of two parts: first, the access proxy component Envoy intercepts application traffic and performs actual authorization checks based on indicator data; second, the indicator collection component Prometheus Pod, acting as an exporter, actively pulls indicator data exposed by business Pods and reports it to the indicator storage system (Prometheus).

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

[0072] Step S201: Obtain the authorization policy configuration; the authorization policy configuration includes the 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 configuration contents not only cover the basic attributes of the policy, such as name, description, effective start and end time, and current authorization status, but also include key associated 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 (such as POST, GET, etc.), request path (such as specific API interface path), associated metric name (such as number of connected devices, QPdevice_numS, etc.), metric limit expression used to define authorization boundaries (such as "sum(probe_target_metric{metric=='device_num'})<=10"), and authorization response (allow or deny) and exception handling strategy (such as graceful degradation when QPS exceeds the limit, entering read-only mode when authorization expires, etc.) when the metric data meets or does not meet the expression.

[0074] Step S202: Based on the service name, determine the target business deployment unit from multiple business deployment units in the data plane, and inject the preset access proxy component into the target business deployment unit in the data plane; convert the authorization policy configuration 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.

[0075] Specifically, after obtaining the authorization policy configuration containing the service name, the indicator authentication service in the control plane first uses the service name as the core identifier to accurately match among numerous business deployment units (such as business PODs in a Kubernetes cluster) in the data plane, locating the target business deployment unit that needs to apply the authorization policy. Then, it injects a pre-defined access proxy component into the target business deployment unit. Simultaneously, the indicator authentication service converts the authorization policy configuration, transforming key information such as the service name, request path, request method, and indicator name into a native access control policy and pushing it to the injected access proxy component in the target business deployment unit. The access proxy component automatically performs hot reloading of the configuration, allowing the new policy to take effect immediately without a restart, thus laying the foundation for subsequent interception of external requests and execution of authorization checks. This approach ensures a tight binding between the access proxy component and the target business deployment unit; even if the business deployment unit subsequently migrates (such as Pod restarts or migrations), the access proxy component will follow suit, continuously maintaining the existence of the policy execution platform.

[0076] Step S203: In response to the external data verification and authorization request sent by the data plane, the external data verification and authorization request is parsed to obtain the requested metric name, the requested service name, and the requested rule name; the external data verification and 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 will accurately obtain the request indicator name (i.e., the dynamic indicator that needs to be verified in the request, such as the number of devices accessed, QPS, etc.), the request service name (i.e., the name of the target business service accessed by the request), and the request rule name (i.e., the specific rule identifier in the authorization policy corresponding to the request) related to the current request. This parsing process is a key prerequisite for the subsequent control plane to query real-time indicator data, match indicator restriction expressions, and generate authorization results. The entire mechanism for initiating the external data verification authorization request realizes effective linkage between the data plane and the control plane regarding authorization verification, ensuring that authorization checks can be dynamically triggered based on specific request scenarios.

[0078] Step S204: Obtain 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 acquisition component (such as the Probe Pod) uses a proactive pull model to periodically and cyclically call various metric data query interfaces exposed by multiple business deployment units. These interfaces correspond to different business metrics (such as the number of connected devices, QPS, and the number of GPU NICs). After the metric acquisition component organizes the aggregated multi-dimensional metric data, it remotely writes it into the metric storage system (such as Prometheus) by calling a specific interface (such as " / api / v1 / write") to ensure that real-time metric data is continuously and accurately stored. When the metric authentication service in the control plane parses the external data verification authorization request and obtains the requested metric name (such as "device_num") and the requested service name (such as "videocloud-device"), it initiates a precise query to the metric storage system based on these two key identifiers. The metric storage system then filters out the corresponding metric type based on the requested metric name and locates the metric data generated by the specific business deployment unit under that service based on the requested service name. Finally, it feeds back the real-time metric data that meets the conditions (such as the real-time statistics of the current number of connected devices) 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. It lays a solid data foundation for accurately judging whether the indicator meets the restriction conditions and generating the correct authorization result. It also reflects the accuracy and relevance of data flow in the entire authorization control method.

[0080] Step S205: Based on the request rule name, determine the indicator restriction expression and the corresponding authorization response.

[0081] Specifically, when the indicator authentication service in the control plane 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. Through precise matching, it locates the corresponding rule item and extracts the indicator restriction expression used to determine the authorization boundary from that rule item. This expression typically contains the calculation logic and threshold conditions for a specific indicator (such as the number of connected devices or QPS). It also determines the authorization response type bound to the expression (i.e., whether to return "allow" or "deny" when the indicator 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 invoked during real-time indicator verification, giving the generation of authorization responses a clear policy basis. It achieves flexible binding of rules, indicators, and responses, while also ensuring the consistency and traceability of the authorization logic, providing crucial rule support for subsequent calculations using real-time indicator data and the generation of the final authorization result.

[0082] Step S206: Generate authorization results based on real-time indicator data, indicator restriction expressions, and authorization responses.

[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 service name, for example, the current value of the "device_num" metric for the "videocloud-device" service. It then substitutes this data into the metric constraint expression determined by the request rule name (e.g., "sum(probe_target_metric{metric='device_num'})<=10") to calculate the result. Subsequently, it combines this with the authorization response corresponding to the metric constraint expression (i.e., the preset "allow" or "deny" rule) and generates the final authorization result through logical judgment. This mechanism dynamically combines real-time business data with preset policy rules, achieving flexible authorization control based on actual business load while ensuring the objectivity and consistency of authorization judgments. It effectively supports fine-grained management of multi-dimensional metrics such as the number of connected devices and QPS, and provides a decision-making basis for anomaly handling (such as graceful degradation when QPS exceeds limits).

[0084] Steps S201 to S206 above achieve centralized and standardized management of authorization policies by uniformly acquiring authorization policy configurations and accurately locating target business deployment units based on service names. This is achieved through dynamic injection of access proxy components and standardized push of native access control policies, avoiding inconsistencies in standards and broken cross-service authorization verification chains caused by independent implementation of authorization mechanisms by various business departments. Furthermore, by leveraging the access proxy component to initiate verification requests based on native policies, parse requests in the control plane, and associate them with real-time indicator data, combined with the mechanism of indicator constraint expressions and authorization response generation, fine-grained authorization control based on dynamic indicators is achieved. The access proxy component's synchronous existence as business deployment units migrate ensures the continuity and effectiveness of authorization during dynamic scaling or container migration in a cloud-native environment. Ultimately, this achieves a unified, dynamic, and fine-grained software authorization control effect that balances the security of private deployments with the flexibility of cloud-native systems, solving the problem of complex management and potential control failures in large-scale distributed systems with cloud-native microservice architectures.

[0085] In some embodiments, the authorization policy configuration can be obtained online or offline;

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

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

[0088] Specifically, the method for obtaining authorization policy configurations flexibly covers both online and offline acquisition modes to adapt to authorization management needs in different scenarios. When using the online acquisition method, the entire process uses the unified authorization management platform as the core data source. The indicator authentication service directly retrieves the configured authorization policy configurations from the platform's database by calling pre-defined interfaces (such as standardized interfaces specifically for policy acquisition). This configuration information is entered and stored by users on the unified authorization management platform through operations such as creating forms, and includes detailed content such as the policy name, description, rule items, effective time, associated account and service name, ensuring that the indicator authentication service can synchronize the latest authorization policies in real time. When network conditions do not meet the requirements for the indicator authentication service to call the unified authorization management platform's open interface for obtaining authorization policies, and an offline acquisition method can be used, the process revolves around a 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, using tools such as scaffolding, the authorization file is imported into the preset indicator authentication service. The indicator authentication service loads and parses the imported authorization file, extracting complete authorization policy configuration information, including the restrictions of each rule, the effective time, and the associated services. This ensures the accurate acquisition and application of authorization policies even when there is no online connection with the unified authorization management platform.

[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 platform configuration updates. This meets the system's requirements for the real-time performance and consistency of the authorization policy when the network is unobstructed, and avoids the problem of policy lag. On the other hand, the offline acquisition method, by importing the authorization file into the indicator authentication service, 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 achieves the flexibility and adaptability of authorization policy management, but also ensures the stability and reliability of authorization control in different network environments. This 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, the step of determining the target business deployment unit from multiple business deployment units in the data plane based on the service name, and injecting a preset access proxy component into the target business deployment unit in the data plane, includes:

[0091] Based on the service name, the target business deployment unit is determined from the plurality of business deployment units, and the component injection tag of the target business deployment unit is set through the preset service mesh management component;

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

[0093] Specifically, firstly, 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 Kubernetes cluster by multiple departments in the data plane. Next, the configuration of the target business deployment unit is adjusted with the help of a preset service mesh management component (such as Issued). By setting a specific component injection flag (such as adding the key-value pair sidecar.istio.io / inject: "true"), it is clearly indicated that an access proxy component needs to be injected into the target business deployment unit. Subsequently, based on this component injection flag, 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 containers in the target business deployment unit, thereby achieving the interception and management of 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 targeting and accuracy of the access proxy component injection and avoiding interference with irrelevant business units. Secondly, by using a pre-defined service mesh management component to set the component injection flag and complete the injection, the access proxy component injection process is automated and standardized, eliminating the need for manual operation by business departments and reducing errors caused by human intervention. It also unifies the injection mechanism and solves the problem of fragmented authorization policies. Furthermore, this on-demand injection method allows the access proxy component to be tightly bound to the target business deployment unit. Even if the business deployment unit shifts (such as Pod restarts or migrations), the access proxy component can follow synchronously, ensuring the continuity and effectiveness of authorization control in dynamic resource scenarios. This provides a stable and reliable foundation for subsequent fine-grained authorization control based on dynamic indicator data.

[0095] In some embodiments, based on component injection tags, the access proxy component is injected into the business deployment unit, including:

[0096] When the component injection flag is set to enabled, the access proxy component will be injected into the business deployment unit.

[0097] Specifically, when the component injection flag (i.e., the key-value pair sidecar.istio.io / inject:“true” set on the business deployment unit) is set, 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 to intercept external request traffic in real time and verify and process the requests according to the subsequent authorization policy configuration.

[0098] Through the above steps, the conditionalization and automation of access proxy component injection are achieved. This ensures that business deployment units that require authorization control can accurately access the access proxy to intercept traffic, while avoiding resource consumption or interference for units that do not require authorization control. At the same time, it guarantees the standardization of the injection process, avoids the chaos caused by independent operations by 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, an authorization result is generated based on real-time indicator data, indicator constraint expressions, and authorization responses corresponding to the indicator constraint expressions, including:

[0100] The real-time indicator data is input into the indicator constraint expression for calculation, and the calculation result is obtained.

[0101] Based on the calculation results, indicator constraint expressions, and authorization responses, authorization results are generated.

[0102] Specifically, after receiving an external data verification authorization request (ExtAuthz request) from the access proxy component, the metric authentication service first obtains the request metric name, request service name, and request rule name associated with the intercepted request through the request information. Then, based on the request metric name and request service name, it queries the metric storage system (Prometheus) to obtain the corresponding real-time metric data (such as the number of connected devices, QPS value, etc.). Subsequently, it substitutes this real-time metric data into the preset metric limit expression in the policy rule (e.g., "sum(probe_target_metric{metric='device_num'})<=10") to calculate the specific calculation result. Afterward, it combines the logical relationship between the calculation result and the metric limit expression (such as whether the conditions in the expression are met) and the authorization response corresponding to the metric limit expression (such as "allow" or "deny") to finally determine and return the corresponding authorization result.

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

[0104] In some embodiments, the authorization response includes allowing or denying; based on the calculation result, the indicator restriction expression, and the authorization response, an authorization result is generated, including:

[0105] If the authorization response is allowed, and the calculation result meets the conditions of the indicator restriction expression, then it will be allowed as the authorization result.

[0106] If the authorization response is allowed, but the calculation result does not meet the conditions of the indicator restriction expression, it will be rejected as the authorization result.

[0107] If the authorization response is rejection, and the calculation result meets the conditions of the indicator restriction expression, then rejection will be taken as the authorization result.

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

[0109] Specifically, when the authorization response is preset to allow, if the calculation result obtained by substituting the real-time indicator data into the indicator restriction expression meets the conditions set by the expression (e.g., the number of connected devices does not exceed the limit, QPS is within the threshold range, etc.), then the final generated authorization result is allow; if the calculation result does not meet the conditions of the indicator restriction expression when the authorization response is preset to allow (e.g., the number of connected devices exceeds the upper limit, QPS exceeds the threshold, etc.), then the authorization result is adjusted to deny; when the authorization response is preset to deny, if the calculation result meets the conditions of the indicator restriction expression, then the authorization result remains deny; if the authorization response is preset to deny, but the calculation result does not meet the conditions of the indicator restriction expression, then the authorization result is reversed to allow.

[0110] Through the above steps, the multi-scenario judgment logic combines the preset state of the authorization response with the calculation results of real-time indicator data and the indicator restriction expression conditions. This ensures that the authorization control strictly follows the preset strategy tendency, while also adjusting the authorization results in real time according to dynamically changing business indicators (such as the number of devices connected, QPS, etc.). This achieves fine-grained and highly adaptable authorization management, effectively solving the problem that static control in traditional authorization methods cannot cope with the dynamic changes of large-scale distributed systems. At the same time, it ensures the accuracy and flexibility of authorization judgment, meeting the complex needs of software authorization control in large-scale ICT private deployment projects.

[0111] This embodiment provides another software licensing control method. Figure 3 This is a flowchart of another software licensing control method according to an embodiment of this application, 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 from multiple business deployment units in the data plane based on the service name; the service name is determined by the control plane based on the obtained authorization policy configuration.

[0113] Specifically, the data plane first obtains an access proxy component (such as an Envoy Sidecar container) injected by the control plane. This component is used to intercept business traffic and perform authorization checks. Subsequently, the data plane installs the access proxy component to a specific target business deployment unit (i.e., business POD). This target business deployment unit is precisely determined by the control plane from multiple business deployment units in the data plane based on the service name. The service name is obtained by the control plane by parsing the authorization policy configuration after obtaining it through online calls to the unified authorization management platform interface or offline import of authorization files. Through this process, the precise binding between the access proxy component and the target business deployment unit is achieved.

[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 new format; the native access control policy includes the request method, request path and indicator name.

[0115] Specifically, the access proxy component in the data plane obtains the native access control policy sent by the control plane. The formation process of this native access control policy is as follows: 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 the request method, request path, associated indicator name, indicator restriction expression, and authorization response. Then, these authorization policy configurations are converted into native access control policies (i.e., AuthorizationPolicy). The converted native access control policy specifically includes the request method (such as POST, GET, etc.), request path (such as / api / camera, etc.) related to authorization verification, and associated indicator name (such as device_num corresponding to the number of connected devices, etc.) so that the access proxy component (such as Envoy Sidecar) can accurately intercept and match the corresponding request 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 performs hot reloading of native access control policy configurations, so that new native access control policies can take effect immediately without restarting the component, thereby ensuring that the access proxy component can accurately identify external requests based on the loaded policies.

[0118] Step S304: Obtain external data from the access proxy component; if the external data matches the request method and request path, initiate an external data verification authorization request to the indicator authentication service in the control plane; the external data verification authorization request includes the requested indicator name, the requested service name, and the requested rule name.

[0119] Specifically, when external data (such as HTTP requests) initiated by an external client arrives at the data plane, it is first intercepted by an access proxy component (such as an Envoy Sidecar container) deployed in the target business deployment unit. The access proxy component parses the acquired external data, extracts the request method (such as POST, GET, etc.) and request path (such as / api / camera, etc.), and matches them 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 initiates an external data verification authorization request to the indicator authentication service of the control plane. This request includes the name of the request indicator (such as device_num corresponding to the number of connected devices), the name of the request service (such as videocloud-device), and the name of the request rule (such as the rule identifier "the number of connected devices cannot exceed 10") extracted from the external data, so that the indicator authentication service can query real-time indicator data and perform authorization verification based on this information.

[0120] Step S305: Periodically acquire multiple indicator data from multiple business deployment units, and then aggregate the multiple indicator data and write them into the preset indicator storage system.

[0121] Specifically, the metrics acquisition components in the data plane (such as the Probe Pod) periodically and cyclically call the different metrics data query interfaces exposed by multiple business deployment units (business PODs) in an active pull mode. These metrics data include multi-dimensional information such as the number of connected devices, QPS (queries per second), and the number of GPU cards that can manage multiple devices, corresponding to the real-time status of each business POD during operation. After acquiring these scattered metrics data, the metrics acquisition components will centrally aggregate them and then remotely write the aggregated metrics data directly into the preset metrics storage system (such as Prometheus) by calling the interface " / api / v1 / write". This achieves unified storage and management of various dynamic metrics data, providing a reliable data source for the subsequent metrics authentication service in the control plane to query real-time metrics data during authorization verification.

[0122] Step S306: In response to the query request from 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 metric authentication service in the control plane receives an external data verification and authorization request from an access proxy component (such as EnvoySidecar), it will initiate a query request to a pre-defined metric storage system (such as Prometheus) for the requested metric name (such as device_num corresponding to the number of connected devices) and the requested service name (such as the associated business service name videocloud-device) contained in the request. In response to the query request, the metric storage system will accurately filter out real-time metric data (such as the current number of connected devices and QPS value of a specific service) that match the requested metric name and requested service name from the various metric data that are periodically aggregated and written by the metric collection component (Probe Pod) in its stored data, and send this real-time metric data back to the metric authentication service. This provides accurate dynamic data support for the metric authentication service to subsequently input the metric constraint 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 real-time indicator data and the request rule name.

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

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

[0127] Specifically, when the authorization result is denied, the access proxy component will invoke a preset exception handling strategy to process the external data in a targeted manner based on the metric name associated with the external data (such as QPS, number of connected devices, etc.). These exception handling strategies are preset when configuring authorization policies on the unified authorization management platform. For example, when the metric name is QPS and its corresponding real-time metric data exceeds the threshold set by the restriction expression, resulting in an authorization rejection, 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 that is bound to specific metric names and scenarios, the system can minimize the impact on business continuity while ensuring the effectiveness of authorization control, and improve the system's fault tolerance and user experience under authorization restrictions.

[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 applied specifically 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 request method and path. Combined with multi-dimensional indicator data that is periodically aggregated and written to the indicator storage system, it provides a dynamic basis for real-time authorization verification of the control plane. 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 denied, external data is processed according to the indicator name and preset exception policy (such as graceful degradation when QPS exceeds the limit). This series of processes not only solves the problems of fragmentation of traditional authorization policies and failure of dynamic resource binding, but also realizes fine-grained authorization control based on real-time indicators. At the same time, it ensures the continuity and stability of business under authorization restrictions, meets the security and flexibility requirements of software authorization in large-scale ICT private deployments, and solves the problem of complex management and easy control failure of authorization control in large-scale distributed systems of cloud-native microservice architecture.

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

[0130] Specifically, the authorization result generation process is as follows: After receiving an 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 corresponding authorization response (such as "allow" or "deny") from the preset authorization policy configuration based on the request rule name contained in the request. Subsequently, the indicator authentication service substitutes the real-time indicator data (such as the current number of connected devices, QPS value, etc.) corresponding to the requested indicator name and requested service name retrieved 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 (i.e., whether the conditions in the expression are met) and the preset authorization response.

[0131] Through the above embodiments, the indicator authentication service accurately determines the corresponding indicator restriction expression and authorization response based on the request rule name, and generates authorization results by combining real-time indicator data. This achieves a deep correlation between authorization judgment and dynamic business indicators, ensuring that authorization control strictly follows preset policy rules while flexibly adjusting authorization results according to real-time business status (such as the number of devices connected, QPS, etc.). This meets the needs of multi-dimensional and fine-grained authorization control in large-scale ICT private deployments. 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 fragmented authorization policies and coarse control granularity, ensures the accuracy and dynamic adaptability of authorization judgment, and provides reliable support for authorization management in distributed systems.

[0132] Figure 4 This is an external data authorization control flowchart according to an embodiment of this 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 HTTP requests sent by external clients. If the request matches the preset access control policy, it sends 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 obtaining 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 allowed range), determines whether to allow or deny the request, and then sends the result back to the access proxy component.

[0135] Step S403: Forward legitimate requests. After the access proxy component receives the "allow" result returned by the indicator authentication service, it forwards the previously intercepted and dynamically checked HTTP request to the corresponding business service, enabling the business service to receive and process the request.

[0136] Step S404: Return 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 performing business calculations. After processing, it generates the corresponding response data and then sends the response back to the access proxy component.

[0137] Step S405: Return the 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 interaction process from request initiation to response reception.

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

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

[0140] Step S502: The metric authentication service notifies the service mesh management component. After obtaining the authorization policy configuration, the metric authentication service, on the one hand, locates the business Pod based on the service name and notifies the service mesh management component Istiod to change the tag of the business Pod, adding the key-value pair sidecar.istio.io / inject: "true", triggering injection into the Envoy Sidecar container; on the other hand, it converts the authorization configuration content (such as service name, request path, request method, metric name) into Istio's native access control policy AuthorizationPolicy, and notifies the Istiod component to push the changed configuration to the relevant Envoy Sidecar container via xDS (gRPC stream). Envoy automatically completes hot reloading of the configuration, and the new policy takes effect immediately, starting to allow / deny requests according to the rules.

[0141] Step S503: Access proxy component intercepts external data. When external data attempts to access the business container within the business deployment unit, the access proxy component deployed in the business deployment unit will intercept this 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 business container.

[0142] In step S504, the metric collection component actively pulls metrics and reports them to the metric storage system. Different business Pods provide different metric data query interfaces, which are uniformly and periodically called by the metric collection component, the Probe Pod, to aggregate metric data. Finally, the data is remotely written directly to Prometheus by calling the Prometheus interface " / api / v1 / write".

[0143] Step S505: The access proxy component initiates an external data verification authorization request to the metrics authentication service. When an external data request accesses a business Pod, the access proxy component intercepts all traffic to 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 will initiate an external data verification authorization request (ExtAuthz request) to the metrics authentication service according to the EnvoyFilter configured in Istio, and wait for the authorization processing result. All other requests are allowed directly. (EnvoyFilter is a configuration feature of Istio; Istio itself provides an access control proxy that can initiate ExtAuthz according to the metrics authentication service address configured in EnvoyFilter).

[0144] Step S506: The indicator authentication service queries the indicator storage system for indicator data. After receiving the verification and authorization request from the access proxy component, the indicator authentication service initiates a query operation to the indicator storage system to obtain the indicator data required for authorization (such as querying the device access count indicator stored in the indicator storage system to determine whether the current number of connected devices exceeds the limit). The service then extracts the corresponding indicator information from the indicator storage system and stores the obtained data in the cache database.

[0145] Step S507: The indicator authentication service returns the authorization result. The indicator authentication service combines the real-time indicator data queried from the indicator storage system with the authorization policy rules to make an authorization judgment, and then returns the authorization result of allowing or denying to the access proxy component, so that the access proxy component can decide whether to allow external data to enter the business container based on the result.

[0146] Through the above steps, firstly, the software authorization control logic is decentralized, resolving the fragmentation of authorization policies: Based on a core architecture of control plane and data plane, the authorization rule definition is deeply integrated with the service mesh's AuthorizationPolicy on the control plane, achieving centralized declarative authorization management configuration through Kubernetes CRDs (custom resources); on the data plane, the access control proxy can bypass external access, eliminating the need for business departments to implement software authorization logic themselves. Secondly, the authorization control logic adopts a dynamic injection approach, avoiding the problem of dynamic resources and authorization binding failure: After injecting the access control proxy into the business Pod as needed, even if the business Pod migrates, the access control proxy will migrate synchronously, continuously maintaining the binding relationship until the relevant authorization policy is deleted. Thirdly, fine-grained authorization control is achieved: a closed-loop feedback mechanism from control theory is introduced, dynamically limiting authorization limits based on real-time business metrics (such as API request rate), and allowing for the free combination of policy-related rules and rule-related metrics to meet fine-grained control requirements.

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

[0148] The first step is to initialize and deploy the software licensing system. First, install Istio. This can be done using the official tool "istioctl" on the Kubernetes cluster by executing "istioctl install --set profile=default-y". Next, prepare the Deployment manifest files for the unified licensing management platform "authmesh-manager", the indicator authentication service "authz-server", and the indicator collection component "authmesh-probe". Deploy them using "kubectl apply -f". Finally, modify the Istio "extensionProviders" configuration to specify the indicator authentication service "authz-server".

[0149] The second step is to adjust the configuration of the metric collection component. Modify the metric collection component configuration file config.yaml, setting the Kubernetes metric discovery mode to "pod", the metric name to "device_num", the metric interface path to " / pu / count", and the associated Pod tag to "app=videocloud-device". This step involves configuring the Probe Pod; a single business service can have multiple Pods, and the associated tag is used to filter out relevant 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 "Allow". 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 an 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". The first ten times will have a normal response. 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. can 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 acquire 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 into a 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 external data verification and authorization requests sent by the data plane, parse the external data verification and authorization requests, and obtain the requested metric name, requested service name, and requested rule name; the external data verification and authorization requests are 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 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;

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

[0161] The authorization result generation module 66 is used to generate authorization results based on real-time indicator data, indicator restriction expressions, and authorization responses.

[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 reside in the same processor; or the above modules can be located in different processors in any combination. Specific examples in this embodiment can be found in the examples described in the above embodiments and optional implementations, and will not be repeated in this embodiment.

[0163] Furthermore, in conjunction with the software licensing control methods in the above embodiments, this application embodiment can provide a storage medium for implementation. This storage medium stores a computer program; when the computer program is executed by a processor, it implements any of the software licensing control methods in the above embodiments.

[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, data stored, data displayed, 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 understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, 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 many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0166] Those skilled in the art should understand that the technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been 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 embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A software licensing control method, characterized in that, Applied to the control plane, the method includes: Obtain the authorization policy configuration; the authorization policy configuration includes the 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 format-converted 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 and authorization request sent by the data plane, the external data verification and authorization request is parsed to obtain the requested metric name, the requested service name, and the requested rule name. The external data verification and authorization request is obtained by the access proxy component from external data, parsed to extract the request method and request path of the external data, and matched with the request method and request path in the native access control policy based on the request method and request path of the external data. The request is sent only if the request method and request path of the external data match the request method and request path in the native access control policy. Obtain 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; Based on the request rule name, determine the indicator restriction expression and the corresponding authorization response; Based on the real-time indicator data, the indicator restriction expression, and the authorization response, an authorization result is generated.

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

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

4. The software licensing control method according to claim 3, characterized in that, The step of injecting the access proxy component into the target business deployment unit based on the component injection tag includes: When the component injection flag is set, the access proxy component is injected into the target business deployment unit.

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

6. The software licensing control method according to claim 5, characterized in that, The authorization response includes allowing or denying; generating the authorization result based on the calculation result, the indicator restriction expression, and the authorization response includes: If the authorization response is permitted, and the calculation result meets the conditions of the indicator restriction expression, then it will be allowed as the authorization result. If the authorization response is allowed, but the calculation result does not meet the conditions of the indicator restriction expression, it will be rejected as the authorization result. If the authorization response is a rejection, and the calculation result meets the conditions of the indicator restriction expression, then rejection will be taken as the authorization result. If the authorization response is a rejection, and the calculation result does not meet the conditions of the indicator restriction expression, then it will be allowed as the authorization result.

7. A software licensing control method, characterized in that, Applied to the data plane, the method includes: Obtain the access proxy component injected by the control plane, and install the access proxy component into the target business deployment unit determined by the control plane from multiple business deployment units in the data plane based on the 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 the indicator authentication service of the control plane after converting the preset authorization policy configuration into a new format; the native access control policy includes the request method, request path, and indicator name; Load the native access control policy into the access proxy component; External data is obtained from the access proxy component; if the external data matches the request method and the request path, an external data verification authorization request is initiated to the indicator authentication service of the control plane; the external data verification authorization request includes the requested indicator name, the requested service name, and the requested rule name; The system periodically acquires multiple indicator data from the multiple business deployment units, aggregates the multiple indicator data, and writes it into a preset indicator storage system. In response to the query request of the indicator authentication service, real-time indicator data is queried in the indicator storage system and sent to the indicator authentication service; the real-time indicator data corresponds to the requested indicator name and the requested service name; 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; If the authorization result is rejected, the external data is processed according to the indicator name and the preset exception handling strategy.

8. The software licensing 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, which identifies the indicator restriction expression and the corresponding authorization response. This is obtained based on the real-time indicator data, the indicator restriction expression, and the authorization response.

9. A software licensing control device, characterized in that, The device, applied to a control plane, includes: The authorization policy acquisition module is used to acquire authorization policy configuration; the authorization policy configuration includes the service name; The access proxy injection and policy push module 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 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; The verification request parsing module is used to respond to external data verification and authorization requests sent by the data plane, parse the external data verification and authorization requests, and obtain the request indicator name, request service name, and request rule name. The external data verification and authorization request is obtained by the access proxy component from external data, parsing the external data, extracting the request method and request path of the external data, matching the request method and request path in the native access control policy based on the request method and request path of the external data, and sending it only if the request method and request path of the external data match the request method and request path in the native access control policy. The real-time indicator data acquisition module is used to 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; The authorization rule determination module is used to determine the indicator restriction expression and the corresponding authorization response 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 licensing control method according to any one of claims 1 to 8 when it is run.

Images