Authorization method and device and storage medium

Abstract

The embodiment of the invention provides an authorization method, equipment and a storage medium. Deployment of an authorization server in a first cloud network is proposed. On the basis, on one hand, an equipment driving component in the first cloud network can initiate an authorization request to the authorization server, and the authorization server performs identity verification on an instance pointed by the authorization request and sends a verification passing message under the condition that the identity verification is passed; and on the other hand, after receiving the verification passing message, the device driving component also detects whether the verification passing message is sent by the authorization server for the instance in which the device driving component is currently located or not. Thus, it can be ensured that all authorized instances pass identity verification based on the authorization server, it can also be ensured that the instances where the instances are located are not embezzles based on the equipment driving assembly, the two aspects are matched with each other, the situation that the embezzles activate equipment driving logic in the equipment driving assembly can be effectively avoided, and therefore safety control over the equipment driving assembly is achieved.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular, to an authorization method, device, and storage medium. Background Art

[0002] In the field of cloud computing, an instance is a virtual computing server on the cloud. Device drivers can be installed in the instance, and the required hardware device functions can be enabled through the device drivers. Among them, some device drivers need to be authorized before they can be activated for use.

[0003] Currently, usually the license provided by the device manufacturer is stored in a license server (License Server). After the instance is started, the device driver installed therein needs to initiate a license application to the specified license server. After obtaining the license issued by the license server, the device driver can be activated to complete device enabling.

[0004] Under this authorization scheme that relies on the license, the problem of license theft often occurs, bringing greater security risks and losses. Summary of the Invention

[0005] Multiple aspects of this application provide an authorization method, device, and storage medium to improve the security control of device drivers.

[0006] An embodiment of this application provides an authorization method applicable to a device driver component. The method includes:

[0007] After the target instance where it is located is started, if it is determined that the target instance is in the first cloud network, an authorization request is sent to the authorization server deployed in the first cloud network to trigger the authorization server to authenticate the target instance;

[0008] When receiving the verification passed message, detect whether the verification passed message is sent by the authorization server for the current instance where the device driver component is located;

[0009] If so, activate the subsequent device driver logic.

[0010] An embodiment of this application also provides an authorization method applicable to an authorization server deployed in the first cloud network. The method includes:

[0011] After receiving an authorization request initiated by any device driver component loaded in any target instance in the first cloud network, authenticate the target instance;

[0012] If it is determined that the target instance passes the authentication, a message indicating successful authentication is returned to the device driver component to trigger the device driver component to activate subsequent device driver logic.

[0013] This application also provides an authorization method applicable to a proxy server deployed in a first cloud network for any other cloud network. The method includes:

[0014] After receiving an authorization request initiated by any device driver component loaded in any target instance in the cloud network served by itself, authenticate the target instance;

[0015] If it is determined that the target instance passes the authentication, forward the authorization request to an authorization server deployed in the first cloud network to trigger the authorization server to authenticate the proxy server and generate a message indicating successful authentication for the authorization request after determining that the proxy server passes the authentication;

[0016] Forward the message indicating successful authentication sent by the authorization server to the device driver component to trigger the device driver component to activate subsequent device driver logic.

[0017] This application also provides a computing device, including a memory, a processor, and a communication component;

[0018] The memory is used to store one or more computer instructions;

[0019] The processor is coupled to the memory and the communication component and is used to execute the one or more computer instructions to execute any of the foregoing authorization methods.

[0020] This application embodiment also provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed by one or more processors, the one or more processors are caused to execute any of the foregoing authorization methods.

[0021] In an embodiment of the present application, a new authorization scheme is proposed, and an authorization server is deployed in a first cloud network. Based on this, on the one hand, a device driver component in a target instance in the first cloud network can initiate an authorization request to the authorization server, and the authorization server will authenticate the target instance and send a verification passed message in the case of successful authentication; on the other hand, after receiving the verification passed message, the device driver component will also detect whether the verification passed message is sent by the authorization server for the instance where the device driver component is currently located. In this way, it can be ensured based on the authorization server that all authorized target instances have passed authentication, and it can also be ensured based on the device driver component that the instance where it is located is not an appropriator. These two aspects cooperate with each other to effectively avoid an appropriator from activating the device driver logic in the device driver component. Accordingly, in this embodiment, the traditional license-dependent authorization scheme is abandoned, and instead, multi-loop authentication is used to prevent a target instance that has not passed authentication from activating the device driver component by using the authorization server, thereby realizing the secure control of the device driver component. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0023] Figure 1 is a logical schematic diagram of a traditional license-dependent authorization scheme;

[0024] Figure 2a is a schematic structural diagram of an authorization system provided by an exemplary embodiment of the present application;

[0025] Figure 2b is an optional schematic structural diagram of an authorization system provided by an exemplary embodiment of the present application;

[0026] Figure 3 is a logical schematic diagram of an authorization scheme in a first cloud network provided by an exemplary embodiment of the present application;

[0027] Figure 4 is a schematic structural diagram of another authorization system provided by an exemplary embodiment of the present application;

[0028] Figure 5 is a logical schematic diagram of an authorization scheme in a non-first cloud network provided by an exemplary embodiment of the present application;

[0029] Figure 6 is a schematic flowchart of an authorization method provided by another exemplary embodiment of the present application;

[0030] Figure 7Schematic diagram of the processing flow of a device driver component provided in another exemplary embodiment of the present application in a first cloud network;

[0031] Figure 8 Schematic diagram of the processing flow of a device driver component provided in another exemplary embodiment of the present application in other cloud networks outside the first cloud network;

[0032] Figure 9 Schematic diagram of the flow of another authorization method provided in another exemplary embodiment of the present application;

[0033] Figure 10 Schematic diagram of the flow of yet another authorization method provided in another exemplary embodiment of the present application;

[0034] Figure 11 Schematic diagram of the structure of a computing device provided in yet another exemplary embodiment of the present application. Detailed implementation manners

[0035] To make the objectives, technical solutions and advantages of the present application clearer, the technical solutions of the present application will be clearly and completely described below in conjunction with specific embodiments of the present application and the corresponding drawings. Apparently, the described embodiments are only a part rather than all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without making creative efforts shall fall within the protection scope of the present application.

[0036] Before starting to elaborate on the technical solutions provided in the embodiments of the present application, several technical concepts involved in the present application are briefly explained as follows.

[0037] Physical host Host: It is a physical server in the field of cloud computing and can provide the necessary hardware resources for the instances created thereon.

[0038] Instance: It refers to a virtual computing server on the cloud and includes basic components such as vCPU, memory, operating system, network, and disk. An operating system (referred to as the guest operating system Guest OS) can be installed in the instance, and the device driver component can be installed in the operating system of the instance.

[0039] License server: The full English name is License server, which is used to provide a license License for the device driver activation process. The license is usually provided by the device manufacturer and stored in the license server. Different devices from different manufacturers need to deploy independent license servers respectively.

[0040] Device driver component: A program component used to enable the functions of a hardware device, which can be installed in the operating system of an instance to enable the required hardware device functions in the instance. Herein, the hardware device refers to various external devices assembled on a physical host.

[0041] Figure 1 It is a logical schematic diagram of a traditional license-dependent authorization scheme. Refer to Figure 1 , the device driver component in the target instance needs to send a license application to the license server. The license server will verify whether the hardware information provided by the device driver component is compatible with the hardware devices managed by the license server. If it is compatible, the license server will issue a license to the device driver component. After receiving the license, the device driver component can activate the device driver logic.

[0042] As mentioned in the background art, in this license-dependent authorization scheme, license theft often occurs. For example, the device driver component in the target instance A provided by a cloud provider applies for a license from the license server, but the target instance B not provided by this cloud provider can steal the license applied for by the target instance A, and based on the stolen license, the device driver component in the target instance B can be activated without any obstacles. The inventor found during the research process that the original intention of setting up the authorization link is usually for security or economic benefits. Therefore, such theft will bring relatively large security risks and losses to both device manufacturers and cloud providers.

[0043] For this reason, in this embodiment, a new authorization scheme is proposed to abandon the traditional license-dependent authorization method to improve the security control of the device driver component.

[0044] The following will describe in detail the technical solutions provided by each embodiment of the present application with reference to the accompanying drawings.

[0045] Figure 2a It is a structural schematic diagram of an authorization system provided by an exemplary embodiment of the present application. As Figure 2a shown, the system includes: an authorization server and several physical hosts for providing hardware resources for target instances.

[0046] In this embodiment, the authorization server can be deployed in the first cloud network. In this embodiment, the cloud network can be understood as a cloud computing service system formed by interoperable instances. From the perspective of physical hosts, the cloud network can include several physical hosts. Based on the hardware resources provided by these physical hosts, instances can be created on these physical hosts, and these instances can communicate with each other. Based on these instances, cloud computing services can be realized. Usually, instances in different cloud networks do not communicate with each other, that is, different cloud networks are usually isolated from each other. In this embodiment, the attributes of different cloud networks may not be exactly the same. Here, the attributes can at least include service models. Based on the diversity of service models, the cloud network in this embodiment can be implemented as a public cloud, a private cloud, a dedicated cloud, a hybrid cloud, or an edge cloud, etc. The type of the cloud network in this embodiment is not limited. Preferably, the first cloud network in this embodiment can be implemented as a public cloud. Among them, the public cloud can be understood as the computing service provided by cloud providers through the public Internet, facing anyone who hopes to use or purchase it. It may be free or sold on demand, allowing customers to pay according to dimensions such as CPU cycles, storage, or bandwidth usage. This embodiment does not elaborate on other types of cloud networks. It is worth emphasizing here that the authorization server in this embodiment belongs to the cloud provider. In actual applications, different cloud providers should use independent authorization servers respectively.

[0047] In addition, the instances in this embodiment can be Elastic Compute Service (ECS) instances, or bare metal server instances, etc. The type of the instances in this embodiment is not limited, and no more examples are given here. The creation principle of different types of instances is not elaborated here either.

[0048] In this embodiment, it is proposed that a new server can be added in the first cloud network as the authorization server. Of course, the processing logic corresponding to the authorization server can also be added to the existing servers in the first cloud network to reuse the existing server as the authorization server. Preferably, the Metadata Server in the first cloud network can be reused as the authorization server in this embodiment. Among them, the Metadata Server is a server in the first cloud network used to store instance metadata. The instance metadata contains the description information of each target instance in the first cloud network, including but not limited to instance ID, IP address, operating system type, instance running status parameters, and instance identifier, etc. No more examples are given here. Among them, the instance identifier can be used to distinguish different service instances.

[0049] In this embodiment, the instances created on the physical host can support the use of various hardware resources on the physical host, including but not limited to CPU, Graphics Processing Unit (GPU), Data Processing Unit (DPU), Application Specific Integrated Circuit (ASIC), network card, etc., which will not be enumerated here. In practical applications, in order to support the instances to use the relevant functions of the hardware resources without obstacles, it is also necessary to install device driver components in the instances to use the relevant hardware device functions.

[0050] Figure 2b It is an optional structural schematic diagram of an authorization system provided by an exemplary embodiment of the present application. Refer to Figure 2b , a virtualization manager can be deployed in the physical host to create and manage instances. For example, the virtualization manager can be a Virtual Machine Monitor (VMM), also known as a Hypervisor, or it can also be QEMU and KVM, etc. Among them, the instance types created and managed by the virtualization manager can include but not limited to Elastic Compute Service (ECS), Virtual Machine (VM), or container, etc. The virtualization manager is also used to virtualize the hardware resources on the physical host into virtual devices and allocate them for the target instance to use. The target instance can use the virtual devices just like using hardware devices. The processing tasks received by the virtual devices will ultimately be transferred to the corresponding hardware devices for execution, and the execution results will then be transmitted back to the target instance through the virtual devices.

[0051] On this basis, there are at least two operating systems on the physical host: the physical host operating system Host OS and the guest operating system Guest OS. Among them, the physical host operating system and the guest operating system are relative. The physical host operating system is the operating system of the physical host, and the guest operating system is the operating system of the instance. In the instance, the device driver components can be run in its guest operating system to enable the functions of the required hardware devices. For example, for the aforementioned GPU that the target instance needs to use, the GPU driver component can be run in the guest operating system of the target instance to perform GPU driver in the target instance, and then enable the GPU-related functions in the target instance. It should be understood that after the driver is completed, the target instance can normally use the relevant functions of the GPU. In addition, in practical applications, multiple device driver components usually need to be loaded in the target instance ( Figure 2a and Figure 2b(only one is shown in the figure) to drive different devices required by the target instance.

[0052] The device driver component in this embodiment can be understood as a program component for driving device functions. In this embodiment, the device driver component is transformed. Combined with the authorization server proposed in this embodiment, the authorization scheme proposed in this embodiment can be implemented through the mutual cooperation between the transformed device driver component and the authorization server.

[0053] It should be noted that the transformation of the device driver component in this embodiment mainly involves the authorization link therein. For the device driver logic that can be activated after successful authorization, this embodiment will not intervene. In addition, for cloud providers, they can no longer provide the license servers required in traditional license-dependent authorization schemes, so that the target instances provided by cloud providers all need to adopt the authorization scheme provided in this embodiment for the authorization process of the device driver component.

[0054] On this basis, referring to Figure 2a and Figure 2b , for the device driver component, after the instance where it is located starts, it can enter the transformed authorization link in this embodiment. The following will describe the specific logic of the device driver component in the authorization link in detail.

[0055] In this embodiment, the device driver component can determine whether the target instance where it is located is in the first cloud network. For the first cloud network and other cloud networks, the device driver component can adopt different logics for the authorization link.

[0056] Figure 3 It is a schematic diagram of the authorization scheme logic in the first cloud network provided by an exemplary embodiment of the present application. Referring to Figure 2a and Figure 3 , if it is determined that the instance where it is located is in the first cloud network, the device driver component can send an authorization request to the authorization server provided in this embodiment. For the convenience of scheme description, hereinafter, the instance where the device driver component sends the authorization request will be described as the target instance. As mentioned above, the authorization server provided in this embodiment is also deployed in the first cloud network. Therefore, there is a reachable path between the device driver component and the authorization server for communication. It should be understood that in this embodiment, the authorization request sent by the device driver component is different from the license application sent in the traditional scheme. This authorization request has been transformed in terms of field settings and request format into the state agreed upon between the device driver component and the authorization server. The authorization request in this embodiment is used to trigger the processing logic on the authorization server side.

[0057] After the authorization request reaches the authorization server, it can trigger the authorization server to authenticate the instance where the device driver component is located. The authentication in this embodiment can be understood as verifying whether the instance has the permission to activate the device driver logic. The implementation method adopted in the authentication process in this embodiment is not limited, as long as it is ensured that only the instances allowed by the cloud provider can pass the authentication. Several preferred implementation methods will be provided in the subsequent embodiments and will not be elaborated here.

[0058] It should be understood that the authorization server in this embodiment completely abandons the traditional license and instead proposes to determine whether to authorize through authentication. Moreover, in this embodiment, there is no longer a need to set up different servers for different devices to handle authorization. Instead, only a shared authorization server needs to be deployed in the first cloud network to meet the authorization requirements of different device driver components. This can effectively reduce resource waste and lower the management and maintenance costs. In this regard, in the authorization scheme provided in this embodiment, the cloud provider can, as the applicant, apply to the device manufacturers of various devices for the right to use the device driver respectively. On this basis, the cloud provider can use the authorization server and the device driver component provided in this embodiment to cooperate with each other for authentication to achieve secure control of the right to use the device driver and thus avoid the leakage of the right to use the device driver.

[0059] In this embodiment, for the authorization server, after receiving the aforementioned authorization request, if it determines that the target instance where the device driver component is located passes the authentication, it can send a verification passed message as a response to the authorization request. If it determines that the target instance where the device driver component is located fails to pass the authentication, it can reject the authorization. In actual applications, there are various ways to reject the authorization. For example, it can not respond to the authorization request to indicate rejection. Another example is that it can send a rejection message to indicate rejection. This embodiment does not make a limitation in this regard.

[0060] Reference Figure 3 In this embodiment, after the device driver component receives the verification passed message, it will not directly activate the subsequent device driver logic. In this embodiment, it is proposed that after the device driver component receives the verification passed message, it needs to detect whether the verification passed message is sent by the authorization server for the current instance where the device driver component is located. And when the detection result is yes, the device driver component will activate the subsequent device driver logic.

[0061] Here, the detection of the device driver component involves at least two aspects: whether the verification message is issued by the authorization server in this embodiment; whether the verification message is issued for the instance where the device driver component is currently located (after receiving the verification message). The device driver component will activate the subsequent device driver logic only when the detection results of these two aspects are yes. By detecting whether the verification message is issued by the authorization server in this embodiment, the possibility of misappropriation of usage rights by impersonating the authorization server can be effectively avoided; by detecting whether the verification message is issued for the target instance where the device driver component is currently located, the possibility of misappropriation of usage rights by replacing the instance can be effectively avoided.

[0062] For example, target instance A is the target instance that cloud vendor 1 allows to activate the device driver component, while target instance B is provided by other cloud vendors and is therefore not allowed by cloud vendor 1. After initiating an authorization request, the device driver component in target instance A can receive a verification pass message from the authorization server of cloud vendor 1. If the device driver component is also loaded in target instance B and obtains the verification pass message received in target instance A, in this case, the device driver component in target instance B can detect that the verification pass message is not for target instance B, and thus will not activate the subsequent device driver logic.

[0063] It should be understood that this part of the detection logic is encapsulated in the device driver component and cannot be tampered with. Therefore, when the thief runs the device driver component provided in this embodiment, the identity theft problem will be detected, and the subsequent device driver logic cannot be activated; and the thief cannot communicate with the authorization server in this embodiment as agreed and cannot recognize the verification pass message in this embodiment through other device driver components, and cannot activate the subsequent device driver logic. It can be seen that in this embodiment, the problem of misappropriation of use rights can be effectively avoided.

[0064] Continuing from the previous text, for the device driver component, after receiving the verification pass message, if it is detected that the verification pass message is not sent by the authorization server or is not for the instance where the device driver component is currently located, the subsequent device driver logic will no longer be activated. In addition, if the device driver component does not receive the verification pass message after the specified waiting time, the subsequent device driver logic will not be activated. Among them, the specified waiting time here can be configured as needed, and this embodiment does not limit this. For example, it can be configured to 100ms, 2s, 5s, etc. In addition, the timing starting point of the specified waiting time can be the moment when the authorization request is issued. In this way, after the authorization request is issued, the device driver component can start timing. After the timing reaches the specified waiting time, if the verification pass message is not received, the subsequent device driver logic will not be activated.

[0065] As mentioned above, in this embodiment, the device driver component may include program logic for authorization (the program logic in this part has been modified in this embodiment) and program logic for enabling the functions of the hardware device. Here, the subsequent device driver logic that needs to be activated by the device driver component refers to the part of the program logic for using the functions of the hardware device. It should be understood that in this embodiment, if a verification passed message is not received after a specified waiting duration or the received verification passed message fails the detection, it indicates that the instance where the device driver component is located has not passed the verification. Correspondingly, the "program logic for monkey boxing" in the device driver component will not activate the "program logic for enabling the functions of the hardware device". Therefore, the "program logic for enabling the functions of the hardware device" will not be executed, and the instance where the device driver component is located will not be able to use the functions of the corresponding hardware device. The reason for setting the authorization link has been explained above and will not be repeated here. In this way, in this embodiment, it can be ensured that the instance where the device driver component is located cannot activate the subsequent device driver logic in the case of failing the authentication on the authorization server side or the instance local side.

[0066] In summary, in this embodiment, a new authorization scheme is proposed, and an authorization server is deployed in the first cloud network. Based on this, on the one hand, the device driver component in the target instance in the first cloud network can send an authorization request to the authorization server, and the authorization server will authenticate the target instance and send a verification passed message in the case of successful authentication; on the other hand, after receiving the verification passed message, the device driver component will also detect whether the verification passed message is sent by the authorization server for the current instance where the device driver component is located. In this way, it can be ensured based on the authorization server that all authorized target instances have passed the authentication, and it can also be ensured based on the device driver component that its instance is not an appropriator. The two aspects cooperate with each other to effectively prevent an appropriator from activating the device driver logic in the device driver component. Accordingly, in this embodiment, the traditional authorization scheme relying on licenses is abandoned, and instead, multi-ring authentication is used to prevent a target instance that has not passed the authentication from activating the device driver component by using the authorization server, thereby realizing the security control of the device driver component. In addition, in this embodiment, the authorization server can support processing high-concurrency authorization requests, thereby ensuring the authorization processing efficiency, which can effectively avoid the phenomenon in the traditional scheme that the service process on the license server fails to process the request in time, resulting in request timeout and verification failure.

[0067] In the above or following embodiments, multiple implementation methods can be adopted to support the authentication operation in the authorization server. The following provides a preferred implementation method.

[0068] Refer to Figure 3In this preferred implementation: For the device driver component, the instance identifier corresponding to the target instance where it is located can be obtained; and the authorization request carrying the instance identifier is sent to the authorization server. That is to say, when generating the authorization request, the device driver component can obtain in real time the instance identifier corresponding to the target instance where it is located and carry the instance identifier in the authorization request. In this way, the authorization server can parse out the instance identifier from the authorization request and use it as the basis for identity verification.

[0069] For the authorization server, after receiving the authorization request, if the instance identifier is queried from the instance metadata of the first cloud network, a verification passed message can be generated as the response to the authorization request. Corresponding to the optional deployment method of the authorization server mentioned above, if the metadata server in the first cloud network is reused as the authorization server in this embodiment, the authorization server can query the instance metadata stored by itself; in other deployment methods, the authorization server can communicate with the metadata server in the first cloud network to query the instance metadata of the first cloud network. No matter which implementation method, the authorization server can determine whether the instance where the device driver component is located is the target instance already registered in the first cloud network based on the instance metadata and the instance identifier of the first cloud network. If so, it can be determined that the instance where the device driver component is located passes the identity verification.

[0070] In this preferred implementation, the target instances already registered in the first cloud network provided by the cloud provider can pass the identity verification on the authorization server side, while the target instances provided by other cloud providers cannot pass the identity verification on the authorization server side. In this way, in the first cloud network scenario, the authorization scope can be limited to the target instances provided by the cloud provider, thereby avoiding the leakage of the device driver usage rights applied for by the cloud provider.

[0071] It should be understood that the above implementation is only exemplary, and this embodiment can also adopt other implementation methods to support the identity verification operation on the authorization server side. For example, since the device driver component is in the target instance, the authorization request sent from the device driver component uses the instance where it is located as the communication outlet. At the network communication level, the authorization server can perceive the source address information of the authorization request it receives, that is, it can perceive from which target instance the authorization request comes. Based on this, the authorization server can read the identification information such as the IP address of the target instance where the device driver component is located from the specified field of the authorization request and use it as the basis for identity verification; and it can also determine whether the corresponding target instance passes the identity verification by querying whether this identification information exists in the instance metadata of the first cloud network. This embodiment is not limited to this.

[0072] In addition, among these implementation manners that use the instance metadata of the first cloud network as the authentication benchmark, the authorization scope can be limited to all the instances provided by the cloud provider in its first cloud network. This is only an optional authorization scope. The authorization scope in this embodiment can also be limited to some of the instances provided by the cloud provider in its first cloud network. For example, an authorization list can be configured for the cloud provider, and the authorization server can perform authentication based on this authorization list. Instances located within the authorization list will pass the authentication, while target instances not located within the authorization list will not pass the authentication. This authorization list can be customized as needed and supports dynamic updates. In this way, the authorization scope for the cloud provider can be flexibly set by configuring this authorization list.

[0073] In summary, in this embodiment, multiple implementation manners are provided to support the authorization server in performing authentication operations. Through the mutual cooperation between the device driver component and the authorization server, it can be ensured that only the authorization requests sent by the device driver components in the target instances within the authorization scope allowed by the cloud provider can obtain the verification passed messages sent by the authorization server. In this way, in this embodiment, the authorization server essentially sends the verification passed messages for the target instances, which endows the verification passed messages with an identity attribute, and thus the security control of the device driver components can be guaranteed based on the verification passed messages.

[0074] In the above or following embodiments, multiple implementation manners can be adopted to support the device driver component in detecting the verification passed messages received. The following provides a preferred implementation manner.

[0075] Refer to Figure 3 , in this preferred implementation manner: for the authorization server, it can use its own private key to encrypt the instance identifier of the target instance that has passed the authentication to generate a verification passed message. Continuing with the implementation manner of the authorization request provided in the foregoing embodiment, if the instance identifier is carried in the authorization request, the authorization server can use its own private key to encrypt the instance identifier carried in the authorization request to generate a verification passed message. If the instance identifier is not carried in the authorization request, the authorization server can query the corresponding instance identifier of the target instance based on other identifier information it obtains, and then use its own private key to encrypt the queried instance identifier to generate a verification passed message. This can ensure that the verification passed message sent by the authorization server has the identity attribute mentioned above.

[0076] On this basis, for the device driver component, after receiving the verification passed message, it can use the public key corresponding to the authorization server to decrypt the received verification passed message; if the decryption is successful and the instance identifier decrypted from the verification passed message matches the instance where the device driver component is currently located, it can be determined that the verification passed message is sent by the authorization server for the instance where the device driver component is currently located.

[0077] In this preferred implementation, the source verification of the verified message is supported through asymmetric encryption technology to avoid the possibility of unauthorized use by impersonating the authorization server. In practical applications, after receiving the verified message sent by the authorization server, the device driver component can send the verified message and the public key corresponding to the authorization server to the OpenSSL module to verify the identity of the authorization server using the OpenSSL module. If the verification result returned by OpenSSL is successful, it can be determined that the decryption of the verified message is successful. Among them, OpenSSL is an independent security software library that can provide powerful security authentication and other functions. It should be understood that in this preferred implementation, other security authentication technologies can also be used to implement the identity verification of the authorization server, not limited to OpenSSL, and no more examples are given here. By directly carrying the instance identifier of the target instance that has passed the identity verification in the verified message, the identity attribute of the verified message can be effectively clarified, and the instance identifier in the verified message cannot be tampered with, thus providing a reliable detection basis for the detection process in the device driver component.

[0078] Furthermore, in this preferred implementation: the device driver component can obtain the instance identifier of the current instance where the device driver component is located in the case of successful decryption; if the instance identifier decrypted from the verified message is consistent with the instance identifier of the current instance where the device driver component is located, it is determined that the instance identifier decrypted from the verified message matches the current instance where the device driver component is located.

[0079] In this way, in this preferred implementation, the device driver component can complete the source verification of the verified message and the re-identity verification of the current target instance.

[0080] It should be understood that the above implementation is only exemplary. In this embodiment, other implementation methods can also be used to support the device driver component to detect the received verified message. For example, the authorization server can carry other identification information such as the IP address in the verified message that can characterize the identity of the corresponding target instance. Correspondingly, the device driver component can complete the re-identity verification of the target instance where it is located according to these identification information. No more examples of implementation methods are given here.

[0081] In summary, in this embodiment, multiple implementation methods are provided to support the device driver component to detect the received verified message, enabling the device driver component to accurately detect whether the verified message comes from the authorization server provided in this embodiment, and accurately detect whether the verified message can be used in the current instance where it is located, thus effectively avoiding the problem of unauthorized use of the device driver.

[0082] Figure 4 Another structural schematic diagram of an authorization system provided for an exemplary embodiment of the present application. Refer to Figure 4 , in addition to providing the first cloud network, cloud providers can also provide various other cloud networks. This embodiment further proposes a solution for securely controlling the device driver component in other cloud networks. Continuing from the previous text, preferably, in this embodiment, the first cloud network can be implemented as a public cloud, and other networks can be implemented as private clouds, dedicated clouds, hybrid clouds, edge clouds, etc. However, it should be understood that this is only exemplary, and the types of the first cloud network and other cloud networks in this embodiment are not limited to this.

[0083] Refer to Figure 4 , in Figure 1 Based on the system structure shown, this embodiment proposes that in the first cloud network, proxy servers are respectively deployed for other cloud networks provided by cloud providers. The processing logic in the proxy servers proposed in this embodiment will be further described below.

[0084] For the device driver component, if it determines that the instance it is located in is in a second cloud network outside the first cloud network, it will no longer initiate an authorization request to the aforementioned authorization server, but instead initiate an authorization request to the proxy server deployed in this non-first cloud network. Here, the second cloud network can be any cloud network in other networks outside the first cloud network. It should be understood that considering security, as mentioned above, instances in different cloud networks usually do not communicate with each other. In this way, instances in the cloud network have no permission to initiate interactions with the authorization server in the first cloud network. This embodiment does not violate this security principle. Therefore, it is proposed to deploy proxy servers for other cloud networks in the first cloud network, and the proxy server is responsible for authenticating the identity of the authorization requests sent within the cloud network it serves, so that the identity authentication of the target instance can be completed within other cloud networks. In this embodiment, a network channel for accessing the cloud network served by the proxy server can be configured to ensure unobstructed interaction between the proxy server and the device driver components in the cloud network it serves.

[0085] Based on this, in this embodiment, for the proxy server, after receiving an authorization request initiated by any device driver component loaded in any target instance in the cloud network it serves, it can authenticate the identity of the target instance.

[0086] Figure 5 A logical schematic diagram of an authorization scheme in a network other than the first cloud network provided for an exemplary embodiment of the present application. Refer to Figure 5, in this embodiment, similar to the authentication logic in the authorization server, the proxy server can store the instance metadata or the pre-set authorization list in the cloud network it serves to limit the authorization scope in the cloud network it serves. Furthermore, the proxy server can perform authentication operations on the authorization requests occurring in the cloud network it serves based on the authorization scope, so as to ensure the security control of the device driver component in the cloud network it serves and avoid the leakage of the device driver usage right. The authentication logic in the proxy server will not be elaborated here. It should be noted that the proxy server only needs to be responsible for performing authentication operations on the authorization requests occurring in the cloud network it serves.

[0087] In addition, in this embodiment, after the proxy server determines that the target instance pointed to by the authorization request passes the authentication, it can forward the authorization request to the aforementioned authorization server. In this case, although the authorization server no longer needs to be responsible for authenticating the target instance, it needs to be responsible for authenticating the proxy server. Therefore, in this embodiment, after receiving the authorization request forwarded by the proxy server, the authorization server can authenticate the proxy server and generate a verification passed message as the response to the authorization request after determining that the proxy server passes the authentication. Among them, referring to Figure 5 , during the process of the authorization server authenticating the proxy server, the proxy server metadata or the pre-set proxy server list, etc. can be used as the authorization scope, and when it is determined that the proxy server is within the authorization scope, it is determined that the proxy server passes the authentication.

[0088] The manner in which the authorization server generates the verification passed message can be the same as that in the case of the first cloud network and will not be repeated here.

[0089] The authorization server can send the generated verification passed message back to the proxy server, and then the proxy server forwards the verification passed message to the device driver component that issued the authorization request. It should be understood that the authorization server and the proxy server are in the same cloud network, so they can communicate with each other without obstacles. In this embodiment, a network channel for the proxy server to access the cloud network it serves is also configured. Therefore, the proxy server and each instance in the cloud network it serves can also communicate with each other without obstacles, which can ensure that the verification passed message can reach the device driver component in the second cloud network smoothly.

[0090] That is to say, for the authorization requests occurring in the second cloud network, in this embodiment, it is still the authorization server that issues the verification passed message. Moreover, the authorization server will issue the verification passed message only after determining that the proxy server passes the authentication, which can ensure that the proxy server recognized by the cloud provider is processing the authorization requests in the second cloud network, rather than other impostor proxy servers, and thus can effectively avoid the possibility of using right theft by impersonating the proxy server.

[0091] In addition, in this embodiment, for the proxy server, if it is determined that the target instance pointed to by the authorization request fails authentication, the authorization can be refused. Similarly, for the authorization server, if it is determined that the proxy server fails authentication, the authorization can also be refused. In this way, in the second cloud network, for authorization requests occurring in target instances outside the authorization scope configured in the proxy server, they will be refused at the proxy server level. Since the proxy server does not have the ability to send a message indicating successful authentication, the proxy server cannot generate a message indicating successful authentication without the authorization server's awareness. For authorization requests forwarded by proxy servers not permitted by the cloud provider, they will be refused at the authorization server level.

[0092] Accordingly, in other cloud networks outside the first cloud network, after the device driver component sends an authorization request, if the target instance it is in can pass authentication in the proxy server and the proxy server can also pass authentication in the authorization server, the device driver component can successfully receive a message indicating successful authentication. After that, the device driver component can continue to detect whether the message indicating successful authentication is sent by the authorization server for the current instance where the device driver component is located, and if the detection result is yes, activate the subsequent device driver logic. This part of the logic is the same as the processing logic in the first cloud network and will not be repeated here.

[0093] Similarly, in other cloud networks outside the first cloud network, if a message indicating successful authentication is not received after a specified waiting duration or the received message indicating successful authentication is not sent by the authorization server for the current instance where the device driver component is located, the device driver component will no longer activate the subsequent device driver logic. This part of the logic is also the same as the processing logic in the first cloud network and will not be repeated here.

[0094] In summary, in this embodiment, the authorization server can manage the proxy servers (equivalent to one layer of authorization) separately deployed for other cloud networks provided for the cloud provider in the first cloud network, and then the proxy server is responsible for the authentication work in the cloud network it serves (equivalent to another layer of authorization). This way of layer-by-layer authorization can ensure that the device driver usage rights applied for by the cloud provider are only used within the scope of the target instances permitted by it, thereby realizing the secure control of the device driver component in other cloud networks outside the first cloud network.

[0095] Figure 6 The following is a schematic flowchart of an authorization method provided for another exemplary embodiment of this application. This method is applicable to the device driver component. Refer to Figure 6 , this method may include:

[0096] Step 600: After the target instance where it is located is started, if it is determined that the target instance is in the first cloud network, an authorization request is sent to the authorization server deployed in the first cloud network to trigger the authorization server to authenticate the target instance;

[0097] Step 601: When a verification passed message is received, detect whether the verification passed message is sent by the authorization server for the current instance where the device driver component is located;

[0098] Step 602: If so, activate the subsequent device driver logic.

[0099] Figure 7 It is a schematic diagram of the processing flow of a device driver component in the first cloud network provided by another exemplary embodiment of the present application. Refer to Figure 7 , in an optional embodiment, the step of sending an authorization request to the authorization server deployed in the first cloud network may include:

[0100] Obtain the instance identifier corresponding to the target instance;

[0101] Send the authorization request carrying the instance identifier to the authorization server to trigger the authorization server to generate a verification passed message when the instance identifier is queried from the instance metadata of the first cloud network as a response to the authorization request.

[0102] Refer to Figure 7 , in an optional embodiment, step 601 may include:

[0103] Decrypt the received verification passed message using the public key corresponding to the authorization server;

[0104] If the decryption is successful and the instance identifier decrypted from the verification passed message matches the current instance where the device driver component is located, it is determined that the verification passed message is sent by the authorization server for the current instance where the device driver component is located;

[0105] Wherein, the authorization server encrypts the instance identifier corresponding to the instance that has passed the authentication using its own private key to generate a verification passed message.

[0106] Refer to Figure 7 , in an optional embodiment, the method may further include:

[0107] When the decryption is successful, obtain the instance identifier of the current instance where the device driver component is located;

[0108] If the instance identifier decrypted from the verification passed message is consistent with the instance identifier of the instance where the device driver component is currently located, it is determined that the instance identifier decrypted from the verification passed message matches the instance where the device driver component is currently located.

[0109] Figure 8 This is a schematic diagram of the processing flow of the device driver component provided in another exemplary embodiment of the present application in other cloud networks outside the first cloud network. Refer to Figure 8 In an optional embodiment, proxy servers are also deployed in the first cloud network for other cloud networks respectively, and the method further includes:

[0110] If it is determined that the target instance where it is located is in a second cloud network outside the first cloud network, an authorization request is sent to the proxy server corresponding to the second cloud network to trigger the proxy server to authenticate the target instance;

[0111] Wherein, when the proxy server determines that the target instance passes the authentication, the authorization request is forwarded to the authorization server to trigger the authorization server to authenticate the proxy server and return a verification passed message to the proxy server after determining that the proxy server passes the authentication, so that the proxy server forwards the verification passed message to the device driver component.

[0112] In an optional embodiment, the proxy server records the instance metadata corresponding to the cloud network it serves, and when the proxy server finds the instance identifier from the instance metadata it records, it determines that the target instance passes the authentication.

[0113] Refer to Figure 7 and Figure 8 In an optional embodiment, the method may further include:

[0114] If the verification passed message is not received after a specified waiting duration or the received verification passed message is not issued by the authorization server for the instance where the device driver component is currently located, the subsequent device driver logic is not activated.

[0115] It should be noted that for the technical details in the above embodiments of the authorization method, reference can be made to the relevant descriptions of the device driver component in the foregoing system embodiments. To save space, they are not elaborated here, but this should not cause loss of the protection scope of the present application.

[0116] Figure 9 This is a schematic diagram of the process of another authorization method provided in another exemplary embodiment of the present application. This method is applicable to the authorization server deployed in the first cloud network. Refer to Figure 9, the method may include:

[0117] Step 900, after receiving an authorization request initiated by any device driver component loaded in any target instance in the first cloud network, authenticate the target instance;

[0118] Step 901, if it is determined that the target instance passes the authentication, return a verification passed message to the device driver component to trigger the device driver component to continue running the subsequent device driver logic.

[0119] In an alternative embodiment, the step of returning a verification passed message to the device driver component may specifically include:

[0120] Encrypt the instance identifier carried in the authorization request using its own private key to generate the verification passed message;

[0121] Send the verification passed message to the device driver component.

[0122] In an alternative embodiment, proxy servers are also deployed in the first cloud network for other cloud networks respectively, and the method may further include:

[0123] After receiving an authorization request forwarded by any proxy server, authenticate the proxy server;

[0124] If the proxy server passes the authentication, generate a verification passed message for the authorization request;

[0125] Send the verification passed message to the proxy server to trigger the proxy server to forward the verification passed message to the device driver component that initiated the authorization request in the cloud network it serves.

[0126] It should be noted that for the technical details in the above embodiments of the authorization method, reference can be made to the relevant descriptions of the authorization server in the foregoing system embodiments. To save space, they will not be elaborated here, but this should not cause loss of the protection scope of this application.

[0127] Figure 10 The flowchart of another authorization method provided in another exemplary embodiment of this application, this method can be applied to the proxy server deployed in the first cloud network for any other cloud network, refer to Figure 10 , the method may include:

[0128] Step 100, after receiving an authorization request initiated by any device driver component loaded in any target instance in the cloud network served by itself, authenticate the target instance;

[0129] Step 101: If it is determined that the target instance passes the authentication, forward the authorization request to the authorization server deployed in the first cloud network to trigger the authorization server to authenticate the proxy server and generate an authentication passed message for the authorization request after determining that the proxy server passes the authentication;

[0130] Step 102: Forward the authentication passed message sent by the authorization server to the device driver component to trigger the device driver component to activate the subsequent device driver logic.

[0131] In an alternative embodiment, the method may further include:

[0132] If it is determined that the target instance fails the authentication, reject the authorization request.

[0133] It should be noted that for the technical details in the above embodiments of the authorization method, reference can be made to the relevant descriptions of the proxy server in the foregoing system embodiments. To save space, they will not be elaborated here, but this should not cause loss of the protection scope of this application.

[0134] In addition, in some of the processes described in the above method embodiments and the accompanying drawings, there are multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order in which they appear herein or may be executed in parallel. The operation numbers such as 601, 602, etc. are only used to distinguish different operations, and the numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel.

[0135] Figure 11 The structural schematic diagram of a computing device provided for another exemplary embodiment of this application. As Figure 11 shown, the computing device includes: a memory 110, a processor 111, and a communication component 112. The processor 111 is coupled to the memory 110 and the communication component 112 and is configured to execute the computer program in the memory 110.

[0136] In some inventive concepts, Figure 11 the computing device shown can be used as a physical host in the first cloud network or other cloud networks. In this case, one or more target instances can be constructed in the computing device, and the required device driver components are loaded according to the hardware device usage requirements in the target instances. Correspondingly, the processor 111 can execute the computer program in the memory 110 to execute the processing logic related to the device driver component in the foregoing system embodiments. To save space, they will not be elaborated here.

[0137] In other inventive concepts, Figure 11The computing device shown can be used as an authorization server deployed in the first cloud network. In this case, the processor 111 can execute the computer program in the memory 110 to execute the processing logic related to the authorization server in the foregoing system embodiments. For the sake of brevity, it will not be elaborated here.

[0138] In still other inventive concepts, Figure 11 The computing device shown can also be used as a proxy server deployed in the first cloud network for any other cloud network. In this case, the processor 111 can execute the computer program in the memory 110 to execute the processing logic related to the proxy server in the foregoing system embodiments. For the sake of brevity, it will not be elaborated here.

[0139] Further, as Figure 11 shown, the computing device further includes: other components such as a power supply component 113. Figure 11 Only some components are schematically shown in the figure, which does not mean that the computing device only includes Figure 11 the components shown.

[0140] Correspondingly, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, and when the computer program is executed, it can implement the steps in the foregoing method embodiments.

[0141] The above Figure 11 The memory is used to store a computer program and can be configured to store various other data to support operations on the computing platform. Examples of these data include instructions for any application program or method for operating on the computing platform, contact data, phone book data, messages, pictures, videos, etc. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0142] The above Figure 11The communication component therein is configured to facilitate communication, in a wired or wireless manner, between the device where the communication component is located and other devices. The device where the communication component is located can access a wireless network based on a communication standard, such as a WiFi, 2G, 3G, 4G / LTE, 5G, or other mobile communication network, or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component further includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on Radio Frequency Identification (RFID) technology, Infrared Data Association (IrDA) technology, Ultra Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0143] The above Figure 11 The power supply component therein provides power for various components of the device where the power supply component is located. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the device where the power supply component is located.

[0144] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0145] The present application is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate means for implementing the functions specified in Figure One one flow or multiple flows and / or blocks Figure One one block or multiple blocks.

[0146] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including instruction means that implement the functions specified in Figure One one flow or multiple flows and / or blocks Figure OneThe functions specified in one or more boxes.

[0147] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process. Thus, the instructions executed on the computer or other programmable device provide for implementing the steps of the functions specified in one Figure One process or multiple processes and / or boxes Figure One or more boxes.

[0148] It should also be noted that the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, commodity or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, commodity or device. Without further limitation, an element defined by the statement "comprising one..." does not exclude the presence of additional identical elements in the process, method, commodity or device comprising the said element.

[0149] 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 for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. And the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of relevant countries and regions, and corresponding operation entrances are provided for users to choose to authorize or refuse.

[0150] The above are only embodiments of the present application and are not used to limit the present application. For those skilled in the art, various changes and modifications can be made to the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the protection scope of the present application.

Claims

1. An authorization method, characterized in that, Applicable to a device driver component, the method includes: After the target instance where it is located is started, if it is determined that the target instance is in the first cloud network, an authorization request is sent to an authorization server deployed in the first cloud network to trigger the authorization server to authenticate the target instance; When receiving a verification passed message, detect whether the verification passed message is sent by the authorization server for the current instance where the device driver component is located; If so, activate the subsequent device driver logic.

2. The method according to claim 1, wherein Sending an authorization request to an authorization server deployed in the first cloud network includes: Obtain the instance identifier corresponding to the target instance; Send the authorization request carrying the instance identifier to the authorization server to trigger the authorization server to generate a verification passed message as a response to the authorization request when the instance identifier is queried from the instance metadata of the first cloud network.

3. The method according to claim 1, characterized in that, Detecting whether the verification passed message is sent by the authorization server for the current instance where the device driver component is located includes: Decrypt the received verification passed message using the public key corresponding to the authorization server; If the decryption is successful and the instance identifier decrypted from the verification passed message matches the current instance where the device driver component is located, determine that the verification passed message is sent by the authorization server for the current instance where the device driver component is located; Wherein, the authorization server encrypts the instance identifier corresponding to the instance that has passed authentication using its own private key to generate a verification passed message.

4. The method according to claim 3, characterized in that, It further includes: When the decryption is successful, obtain the instance identifier of the current instance where the device driver component is located; If the instance identifier decrypted from the verification passed message is consistent with the instance identifier of the current instance where the device driver component is located, determine that the instance identifier decrypted from the verification passed message matches the current instance where the device driver component is located.

5. The method according to claim 1, characterized in that In the first cloud network, proxy servers are respectively deployed for other cloud networks. The method further includes: If it is determined that the target instance where it is located is in a second cloud network outside the first cloud network, send the authorization request to the proxy server corresponding to the second cloud network to trigger the proxy server to authenticate the target instance; Wherein, when the proxy server determines that the target instance passes authentication, it forwards the authorization request to the authorization server to trigger the authorization server to authenticate the proxy server and return a verification passed message to the proxy server after determining that the proxy server passes authentication, so that the proxy server forwards the verification passed message to the device driver component.

6. The method according to claim 5, wherein The instance metadata corresponding to the cloud network served by the proxy server is recorded in the proxy server. The proxy server determines that the target instance passes authentication when the instance identifier is found from the instance metadata recorded by itself.

7. The method according to claim 1, wherein It further includes: If a verification passed message is not received after a specified waiting duration, or the received verification passed message is not issued by the authorization server for the current instance of the device driver component, subsequent device driver logic is no longer activated.

8. An authorization method, characterized in that, Applicable to an authorization server deployed in a first cloud network, the method includes: After receiving an authorization request initiated by any device driver component loaded in any target instance in the first cloud network, authenticate the target instance; If it is determined that the target instance passes the authentication, return a verification passed message to the device driver component to trigger the device driver component to activate subsequent device driver logic.

9. The method according to claim 8, characterized in that, Returning a verification passed message to the device driver component includes: Using its own private key to encrypt the instance identifier corresponding to the target instance to generate the verification passed message; Sending the verification passed message to the device driver component.

10. The method according to claim 8, wherein Proxy servers are also deployed in the first cloud network for other cloud networks respectively, and the method further includes: After receiving an authorization request forwarded by any proxy server, authenticate the proxy server; If the proxy server passes the authentication, generate a verification passed message for the authorization request; Send the verification passed message to the proxy server to trigger the proxy server to forward the verification passed message to the device driver component that initiated the authorization request in the cloud network it serves; Wherein, the proxy server forwards the authorization request to the authorization server after determining that the instance pointed to by the authorization request passes the authentication.

11. An authorization method, characterized in that, Applicable to a proxy server deployed in the first cloud network for any other cloud network, the method includes: After receiving an authorization request initiated by any device driver component loaded in any target instance in the cloud network it serves, authenticate the target instance; If it is determined that the target instance passes the authentication, forward the authorization request to the authorization server deployed in the first cloud network to trigger the authorization server to authenticate the proxy server and generate a verification passed message for the authorization request after determining that the proxy server passes the authentication; Forward the verification passed message sent by the authorization server to the device driver component to trigger the device driver component to activate subsequent device driver logic.

12. A computing device, characterized in that, Includes a memory, a processor, and a communication component; The memory is used to store one or more computer instructions; The processor is coupled to the memory and the communication component and is used to execute the one or more computer instructions to execute the authorization method according to any one of claims 1-11.

13. A computer-readable storage medium storing computer instructions, characterized in that, When the computer instructions are executed by one or more processors, the one or more processors are caused to execute the authorization method according to any one of claims 1-11.

Images