Authorization method, device, and storage medium

Abstract

The present application provides an authorization method, a device, and a storage medium, and relates to deploying an authorization server in a first cloud network. On this basis, a device driver component in the first cloud network can initiate an authorization request to the authorization server, the authorization server performs identity verification on an instance to which the authorization request is directed, and sends a verification success message when the identity verification succeeds; in addition, after receiving the verification success message, the device driver component also detects whether the verification success message is sent by the authorization server for an instance where the device driver component currently resides. In this way, on the basis of the authorization server, it can be ensured that all the authorized instances have passed identity verification, and on the basis of the device driver component, it can also be ensured that the instance where the device driver component resides is not compromised by an unauthorized entity.

Description

Authorization Method, Device and Storage Medium - Technical Field

[0001] This application relates to the field of cloud computing technology, and particularly 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. After the instance is started, the device driver installed therein needs to send 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 license - dependent authorization scheme, 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: 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; in the case of receiving a verification - passed message, it is detected whether the verification - passed message is sent by the authorization server for the current instance where the device driver component is located; if so, the subsequent device - driver logic is activated.

[0007] An embodiment of this application also provides an authorization method applicable to an authorization server deployed in the 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 the subsequent device - driver logic.

[0008] The present 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: after receiving an authorization request initiated by any device driver component loaded in any target instance in the cloud network served by itself, authenticating the target instance; if it is determined that the target instance passes the authentication, forwarding 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 an authentication passed message for the authorization request after determining that the proxy server passes the authentication; forwarding the authentication passed message sent by the authorization server to the device driver component to trigger the device driver component to activate subsequent device driver logic.

[0009] The present application also provides a computing device including 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 any of the foregoing authorization methods.

[0010] The embodiment of the present application also provides a computer-readable storage medium storing computer instructions, which when executed by one or more processors, cause the one or more processors to execute any of the foregoing authorization methods.

[0011] In the embodiment of the present application, a new authorization scheme is proposed, and an authorization server is deployed in the 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 an authentication passed message when the authentication is passed; on the other hand, after receiving the authentication passed message, the device driver component will also detect whether the authentication 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 the authentication, and it can also be ensured based on the device driver component that the instance where it is located 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 license-dependent authorization scheme is abandoned, and multi-loop authentication is used to prevent unauthenticated target instances from activating the device driver component by using the authorization server, thereby realizing the security control of the device driver component. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0013] FIG. 1 is a logical schematic diagram of a traditional license-dependent authorization scheme;

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

[0015] FIG. 2b is an alternative schematic structural diagram of an authorization system provided by an exemplary embodiment of the present application;

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

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

[0018] FIG. 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;

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

[0020] FIG. 7 is a schematic processing flowchart of a device driver component in a first cloud network provided by another exemplary embodiment of the present application;

[0021] FIG. 8 is a schematic processing flowchart of a device driver component in other cloud networks outside the first cloud network provided by another exemplary embodiment of the present application;

[0022] FIG. 9 is a schematic flowchart of another authorization method provided by another exemplary embodiment of the present application;

[0023] FIG. 10 is a schematic flowchart of yet another authorization method provided by another exemplary embodiment of the present application;

[0024] FIG. 11 is a schematic structural diagram of a computing device provided by yet another exemplary embodiment of the present application. DETAILED DESCRIPTION

[0025] 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 the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts shall fall within the scope of protection of the present application.

[0026] Before starting to provide a detailed description of the technical solutions provided in the embodiments of the present application, several technical concepts involved in the present application are briefly explained as follows.

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

[0028] 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 device driver components can be installed in the operating system of the instance.

[0029] License server: The full English name is License server, which is used to provide a license for the device driver activation process. The license License0 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.

[0030] Device driver component: It is a program component used to enable the functions of hardware devices and can be installed in the operating system of the instance to enable the required hardware device functions in the instance. Among them, the hardware device refers to various external devices assembled on the physical host.

[0031] Figure 1 is a logical schematic diagram of a traditional license-dependent authorization scheme. Referring 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.

[0032] As mentioned in the background art, in this license-dependent authorization scheme, the problem of license theft often occurs. For example, the device driver component in the target instance A provided by the cloud provider to the user applies for a license from the license server, but the target instance B not provided by the 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 the authorization link is usually for security or economic benefits. Therefore, this kind of theft will bring relatively large security risks and losses to both the device manufacturer and the cloud provider.

[0033] To this end, in this embodiment, a new authorization scheme is proposed to abandon the traditional license-dependent authorization method in order to improve the security control of device driver components.

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

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

[0036] The authorization server in this embodiment 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 may include a plurality of 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 may 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 a computing service provided by a cloud provider through the public Internet, Internet, for anyone who wishes 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.

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

[0038] In this embodiment, it is proposed that a new server can be added to the first cloud network as an 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 (Metadata). The instance metadata (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 identifiers, etc., and no more examples are given here. Among them, the instance identifier can be used to distinguish different service instances.

[0039] In this embodiment, it is possible to support the instances created on the physical host to use 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., and no exhaustive list is given 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.

[0040] Figure 2b is an alternative structural schematic diagram of an authorization system provided by an exemplary embodiment of the present application. Referring to Figure 2b, a virtualization manager can be deployed in a 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 can also be QEMU and KVM, etc. Among them, the instance types created and managed by the virtualization manager can include but are 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 use by target instances. The target instances 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 instances through the virtual devices.

[0041] 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, a device driver component 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 GPU-related functions can be normally used in the target instance. In addition, in practical applications, multiple device driver components usually need to be loaded in the target instance (only one is shown in Figure 2a and Figure 2b) to drive different devices required by the target instance.

[0042] 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 realized through the mutual cooperation between the transformed device driver component and the authorization server.

[0043] 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 the traditional license-dependent authorization scheme, so that the target instances provided by the cloud providers need to adopt the authorization scheme provided by this embodiment for the authorization process of the device driver component.

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

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

[0046] FIG. 3 is a schematic diagram of the authorization scheme logic in a first cloud network provided by an exemplary embodiment of the present application. Referring to FIGS. 2a and 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 into the state agreed between the device driver component and the authorization server in terms of field settings and request formats. The authorization request in this embodiment is used to trigger the processing logic on the authorization server side.

[0047] 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 first.

[0048] It should be understood that the authorization server in this embodiment completely abandons the traditional license and instead determines authorization through authentication. Moreover, in this embodiment, there is no longer a need to set up different servers for different devices to handle authorization. Instead, it is only necessary to deploy a shared authorization server in the first cloud network to meet the authorization requirements of different device driver components. This can effectively reduce resource waste and lower management and maintenance costs. In this regard, in the authorization solution provided in this embodiment, the cloud provider can act as the applicant and apply to the device manufacturers of various devices for the right to use the device driver respectively. On this basis, the cloud provider can perform authentication through the cooperation of the authorization server and the device driver component provided in this embodiment 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.

[0049] 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 the authentication, it can reject the authorization. In actual applications, there are various ways to reject 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.

[0050] Referring to FIG. 3, in this embodiment, after receiving the verification passed message, the device driver component does not directly activate the subsequent device driver logic. In this embodiment, it is proposed that after receiving the verification passed message, the device driver component needs to detect whether the verification passed message is sent by the authorization server in this embodiment 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.

[0051] Here, the detection of the device driver component involves at least two aspects: whether the verification passed message is sent by the authorization server in this embodiment; whether the verification passed message is sent for the current instance (after receiving the verification passed message) where the device driver component is located. Only when the detection results of both aspects are yes, the device driver component will activate the subsequent device driver logic. By detecting whether the verification passed message is sent by the authorization server in this embodiment, the possibility of stealing the right to use by impersonating the authorization server can be effectively avoided; by detecting whether the verification passed message is sent for the current target instance where the device driver component is located, the possibility of stealing the right to use by swapping instances can be effectively avoided.

[0052] For example, target instance A is a 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 the verification pass message received in target instance A is obtained, 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 the subsequent device driver logic will not be activated.

[0053] 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 theft of use rights can be effectively avoided.

[0054] In continuation of the above, 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 not 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 time 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.

[0055] As mentioned above, in this embodiment, the device driver component may include program logic for authorization (this embodiment has modified this part of program logic) and program logic for enabling hardware device functions. Here, the subsequent device driver logic required to be activated by the device driver component refers to the part of the program logic used to use the hardware device function. It should be understood that in this embodiment, if the verification pass message is not received after the specified waiting time or the received verification pass message fails to pass the detection, it means that the instance of the device driver component has not passed the verification, and accordingly, The "program logic for monkey fist" in the device driver component will not activate the "program logic for enabling hardware device functions", so the "program logic for enabling hardware device functions" 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 reasons for setting the authorization link have been explained in the previous text, and will not be repeated here. In this way, in this embodiment, it can be ensured that if the instance where the device driver component is located fails to pass the identity authentication of the authorization server instance or fails to pass the identity authentication of the instance local instance, the subsequent device driver logic cannot be activated.

[0056] 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 initiate an authorization request to the authorization server, and the authorization server will authenticate the target instance and send a verification pass message if the authentication is passed; on the other hand, after receiving the verification pass message, the device driver component will also detect whether the verification pass 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 the authorized target instances have all passed the authentication, and it can also be ensured based on the device driver component that the instance where it is located is not an embezzler. These two aspects cooperate with each other to effectively prevent the embezzler from activating the device driver logic in the device driver component. Accordingly, in this embodiment, the traditional authorization scheme that relies on the license is abandoned, and multi-ring identity authentication is used to prevent the target instance that has not passed the identity authentication from using the authorization server to activate the device driver component, 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 authorization processing efficiency, which can effectively avoid the phenomenon in the traditional solution that the service process on the license server cannot process the request in time, resulting in request timeout and verification failure.

[0057] In the above or below embodiments, multiple implementations may be used to support identity authentication operations in the authorization server. A preferred implementation is provided below.

[0058] Referring to FIG. 3 , in the preferred implementation, the device driver component can obtain the instance identifier corresponding to the target instance in which it is located; and send the authorization request carrying the instance identifier to the authorization server. That is, when the device driver component generates the authorization request, it can obtain the instance identifier corresponding to the target instance in which it is located in real time, and carry the instance identifier in the authorization request, so that the authorization server can parse the instance identifier from the authorization request as the basis for identity authentication.

[0059] For the authorization server, after receiving an 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 a 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. Regardless of 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.

[0060] In this preferred implementation method, 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, thus avoiding the leakage of the device driver usage rights applied for by the cloud provider.

[0061] It should be understood that the above implementation methods are 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 its location instance 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 which target instance the authorization request comes from. 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 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.

[0062] 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 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 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 be able to 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.

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

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

[0065] Referring to FIG. 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 identification 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 messages sent by the authorization server have the identity attribute mentioned above. This can ensure that the verification passed messages sent by the authorization server have the identity attribute mentioned above.

[0066] 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 current instance where the device driver component is located, it can be determined that the verification passed message is sent by the authorized server for the current instance where the device driver component is located.

[0067] In this preferred implementation, asymmetric encryption technology is used to support the source verification of the verification passed message to avoid the possibility of unauthorized use by impersonating the authorization server. In practical applications, after receiving the verification passed message sent by the authorization server, the device driver component can send the verification passed message and the public key corresponding to the authorization server to the OpenSSL module to use the OpenSSL module to verify the identity of the authorization server. If the verification result returned by OpenSSL is successful, it can be determined that the decryption of the verification passed 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 verification passed message, the identity attribute of the verification passed message can be effectively clarified, and the instance identifier in the verification passed message cannot be tampered with, thus providing a reliable detection basis for the detection process in the device driver component.

[0068] Furthermore, in this preferred implementation: the device driver component can, in the case of successful decryption, 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, it is determined that the instance identifier decrypted from the verification passed message matches the current instance where the device driver component is located.

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

[0070] It should be understood that the above implementation manners are merely exemplary. In this embodiment, other implementation manners can also be adopted to support the device driver component to detect the verified message received. For example, the authorization server can carry other identification information such as the IP address in the verified message, which 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 manners are given here.

[0071] In summary, in this embodiment, multiple implementation manners are provided to support the device driver component to detect the verified message received, so that the device driver component can accurately detect whether the verified message comes from the authorization server provided in this embodiment, and accurately detect whether the current instance where it is located has the right to use the verified message, thereby effectively avoiding the problem of unauthorized use of the device driver.

[0072] FIG. 4 is a schematic structural diagram of another authorization system provided by an exemplary embodiment of the present application. Referring to FIG. 4, in addition to providing the first cloud network, the cloud manufacturer 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, the first cloud network in this embodiment 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 thereto.

[0073] Referring to FIG. 4, based on the system structure shown in FIG. 1, this embodiment proposes that in the first cloud network, proxy servers are respectively deployed for the other cloud networks provided by the cloud manufacturer. The processing logic in the proxy servers proposed in this embodiment is described in detail below.

[0074] For the device driver component, if it determines that the instance it is in is in the 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, an instance in a cloud network has no permission to initiate an interaction with the authorization server in the first cloud network. In this embodiment, this security principle is not violated, and therefore a proxy server is deployed for each other cloud network in the first cloud network, and the proxy server is responsible for authenticating the authorization requests sent within the cloud network it serves, so that the 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 for the proxy server to ensure that there is unobstructed interaction between the proxy server and the device driver components in the cloud network it serves.

[0075] 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 target instance.

[0076] FIG. 5 is a schematic logical diagram of an authorization scheme in other networks outside the first cloud network provided by an exemplary embodiment of the present application. Referring to FIG. 5, in this embodiment, similar to the authentication logic in the authorization server, the proxy server can store the instance metadata or the preset authorization list in the cloud network it serves to limit the authorization scope in the cloud network it serves, and then perform an authentication operation on the authorization requests occurring in the cloud network it serves according to the authorization scope to ensure the security control of the device driver components in the cloud network it serves and avoid the leakage of the device driver usage rights. 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.

[0077] 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 After determining that the proxy server has passed authentication, a verification passed message is generated as a response to the authorization request. Among them, referring to FIG. 5, during the authentication process of the proxy server by the authorization server, the authorization scope can be based on the proxy server metadata or a preset list of proxy servers, etc., and when it is determined that the proxy server is within the authorization scope, it is determined that the proxy server has passed authentication.

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

[0079] The authorization server can send the generated verification passed message back to the proxy server, and the proxy server then 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 located in the same cloud network, so the two parties can communicate 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 without obstacles, which can ensure that the verification passed message can reach the device driver component in the second cloud network smoothly.

[0080] That is to say, for the authorization request 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 has passed authentication, which can ensure that the proxy server recognized by the cloud provider is used to process the authorization request in the second cloud network, rather than other proxy servers under false names, thereby effectively avoiding the possibility of unauthorized use by impersonating a proxy server.

[0081] In addition, in this embodiment, for the proxy server, if it is determined that the target instance pointed to by the authorization request has not passed authentication, the authorization can be refused. Similarly, for the authorization server, if it is determined that the proxy server has not passed authentication, the authorization can also be refused. In this way, in the second cloud network, for the authorization request occurring in the target instance outside the authorization scope configured in the proxy server, it will be refused at the proxy server level. And since the proxy server does not have the ability to issue a verification passed message, the proxy server cannot generate a verification passed message without the authorization server's awareness. For the authorization request forwarded by a proxy server not allowed by the cloud provider, it will be refused at the authorization server level.

[0082] 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 verification passed message. After that, the device driver component can continue 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 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.

[0083] Similarly, in other cloud networks outside the first cloud network, if the verification passed message is not received after a specified waiting duration or the received verification passed message 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. In summary, in this embodiment, the authorization server can manage the proxy servers separately deployed in other cloud networks provided for cloud providers in the first cloud network (equivalent to one layer of authorization), and then the proxy servers are responsible for the authentication work in the cloud networks they serve (equivalent to another layer of authorization). This way of layer-by-layer authorization can ensure that the device driver usage rights applied for by cloud providers are only used within the target instances allowed by them, thereby realizing the security control of the device driver component in other cloud networks outside the first cloud network.

[0084] FIG. 6 is a schematic flowchart of an authorization method provided by another exemplary embodiment of the present application. This method is applicable to a device driver component. Referring to FIG. 6, this method may include steps 600 to 602.

[0085] 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, send an authorization request to the authorization server deployed in the first cloud network to trigger the authorization server to authenticate the target instance.

[0086] Step 601, 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.

[0087] Step 602, if so, activate the subsequent device driver logic.

[0088]

[0089] ​FIG. 7 is a schematic diagram of a processing flow of a device driver component provided in another exemplary embodiment of the present application in a first cloud network.

[0090] Referring to FIG. 7, in an alternative embodiment, the step of initiating an authorization request to an authorization server deployed in the first cloud network may include: obtaining an instance identifier corresponding to the target instance; sending an 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.

[0091] Referring to FIG. 7, in an alternative embodiment, step 601 may include: decrypting 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 instance where the device driver component is currently located, it is determined that the verification passed message is issued by the authorization server for the instance where the device driver component is currently located; wherein, the authorization server encrypts the instance identifier corresponding to the instance that has passed the identity verification using its own private key to generate a verification passed message.

[0092] Referring to FIG. 7, in an alternative embodiment, the method may further include: in the case of successful decryption, obtaining the instance identifier of the instance where the device driver component is currently located; 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.

[0093] FIG. 8 is a schematic diagram of a 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.

[0094] Referring to FIG. 8, in an alternative embodiment, a proxy server is also deployed in the first cloud network for each of the 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, 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; 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 an authentication passed message to the proxy server after determining that the proxy server passes the authentication, so that the proxy server forwards the authentication passed message to the device driver component.

[0095] In an alternative embodiment, the proxy server records instance metadata corresponding to the cloud network it serves. When the proxy server finds the instance identifier from the instance metadata it records, it determines that the target instance passes the authentication.

[0096] Referring to FIGS. 7 and 8, in an alternative embodiment, the method may further include: if the authentication passed message is not received after a specified waiting duration or the received authentication passed message is not issued by the authorization server for the current instance where the device driver component is located, the subsequent device driver logic is not activated.

[0097] It should be noted that for the technical details in the above embodiments of the authorization method, reference may be made to the relevant descriptions of the device driver component 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.

[0098] FIG. 9 is a flowchart of another authorization method provided by another exemplary embodiment of the present application. This method is applicable to an authorization server deployed in a first cloud network. Referring to FIG. 9, this method may include steps 900 to 901.

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

[0100] Step 901: If it is determined that the target instance passes the authentication, return an authentication passed message to the device driver component to trigger the device driver component to continue running the subsequent device driver logic.

[0101] In an alternative embodiment, the step of returning an authentication passed message to the device driver component may include: encrypting the instance identifier carried in the authorization request using its own private key to generate the authentication passed message; and sending the authentication passed message to the device driver component.

[0102] In an alternative embodiment, a proxy server is also deployed in the first cloud network for each of the other cloud networks. The method may further include: authenticating the proxy server after receiving an authorization request forwarded by any proxy server; if the proxy server passes the authentication, generating an authentication passed message for the authorization request; and sending the authentication passed message to the proxy server to trigger the proxy server to forward the authentication passed message to the device driver component that initiated the authorization request in the cloud network it serves.

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

[0104] FIG. 10 is a schematic flowchart of another authorization method provided by another exemplary embodiment of this application. This method is applicable to a proxy server deployed in the first cloud network for any other cloud network. Referring to FIG. 10, this method may include: step 100 to step 102.

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

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

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

[0108] In an alternative embodiment, the method may further include: if it is determined that the target instance does not pass the authentication, reject the authorization request.

[0109] 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 herein, but this should not cause any loss to the protection scope of this application.

[0110] 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 serial numbers such as 601, 602, etc. are only used to distinguish different operations, and the serial numbers themselves do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel.

[0111] FIG. 11 is a schematic structural diagram of a computing device provided by another exemplary embodiment of the present application. As shown in FIG. 11, 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 a computer program in the memory 110.

[0112] In some inventive concepts, the computing device shown in FIG. 11 can be used as a physical host in a 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 components in the foregoing system embodiments. To save space, it will not be elaborated herein.

[0113] In other inventive concepts, the computing device shown in FIG. 11 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. To save space, it will not be elaborated herein.

[0114] In still other inventive concepts, the computing device shown in FIG. 11 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. To save space, it will not be elaborated herein.

[0115] Further, as shown in FIG. 11, the computing device further includes: a power supply component 113. In some embodiments, the computing device further includes other components such as a display 114 and an audio component 115. Only some components are schematically shown in FIG. 11, which does not mean that the computing device only includes the components shown in FIG. 11.

[0116] 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 above method embodiments.

[0117] The memory in FIG. 11 above 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 such data include instructions for any application 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.

[0118] The communication component in FIG. 11 above is configured to facilitate communication between the device where the communication component is located and other devices in a wired or wireless manner. The device where the communication component is located can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G / LTE, 5G and other mobile communication networks, 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.

[0119] The power supply component in FIG. 11 above 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.

[0120] 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 be implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) that contain computer-usable program code. in the form of a computer program product.

[0121] 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 flowchart and / or block diagram, as well as the combination of flows and / or blocks in the flowchart and / or block diagram, can be realized 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, so that the instructions executed by the processor of the computer or other programmable data processing devices generate a device for realizing the functions specified in one or more flows in the flowchart and / or one or more blocks in the block diagram.

[0122] 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, so that the instructions stored in the computer-readable memory generate a manufactured article including an instruction device, and the instruction device realizes the functions specified in one or more flows in the flowchart and / or one or more blocks in the block diagram.

[0123] 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, and thus the instructions executed on the computer or other programmable device provide steps for realizing the functions specified in one or more flows in the flowchart and / or one or more blocks in the block diagram.

[0124] It should also be noted that the term "including", "comprising" 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.

[0125] 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. Moreover, the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entrances are provided for users to choose to authorize or refuse.

[0126] The above are only the 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

Claims 1. A method for authorization, wherein: Applicable to a device driver component, the method includes: after the target instance in which the device driver component is located is started, if it is determined that the target instance is located in a first cloud network, initiating an authorization request to an authorization server deployed in the first cloud network to trigger the authorization server to authenticate the target instance; in the case of receiving a verification pass message, detecting whether the verification pass message is issued by the authorization server for the instance in which the device driver component is currently located; if so, activating subsequent device driver logic.

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

3. The method according to claim 1, wherein: Detecting whether the verification pass message is issued by the authorization server for the instance in which the device driver component is currently located, includes: decrypting the received verification pass message using the public key corresponding to the authorization server; if the decryption is successful and the instance identifier decrypted from the verification pass message matches the instance in which the device driver component is currently located, determining that the verification pass message is issued by the authorization server for the instance in which the device driver component is currently located; wherein the authorization server uses its own private key to encrypt the instance identifier corresponding to the instance that has passed the identity authentication to generate the verification pass message.

4. The method according to claim 3, further comprising: If the decryption is successful, obtaining the instance identifier of the current instance of the device driver component; If the instance identifier decrypted from the verification pass 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 pass message matches the instance where the device driver component is currently located.

5. The method according to claim 1, wherein: In the first cloud network, proxy servers are deployed for other cloud networks respectively, and the method further includes: if it is determined that the target instance in which the user is located is located in a second cloud network outside the first cloud network, initiating 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 the authentication, the proxy server forwards the authorization request to the authorization server to trigger the authorization server to authenticate the proxy server and After determining that the proxy server passes the identity authentication, a verification pass message is returned to the proxy server, so that the proxy server forwards the verification pass message to the device driver component.

6. The method according to claim 5, wherein: The proxy server records instance metadata corresponding to the cloud network it serves. When the proxy server finds the instance identifier from the instance metadata recorded by itself, it determines that the target instance passes the identity authentication.

7. The method according to claim 1, further comprising: If no verification pass message is received after a specified waiting period or the received verification pass message is not sent by the authorization server for the current instance of the device driver component, the subsequent device driver logic will no longer be activated.

8. An authorization method, wherein: Applicable to an authorized server deployed in a first cloud network, the method comprises: after receiving an authorization request initiated by any device driver component loaded in any target instance in the first cloud network, authenticating the target instance; if it is determined that the target instance passes the identity authentication, returning a verification pass 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, wherein: Returning a verification pass message to the device driver component includes: encrypting the instance identifier corresponding to the target instance using its own private key to generate the verification pass message; and sending the verification pass message to the device driver component.

10. The method according to claim 8, wherein: Proxy servers are also deployed for other cloud networks in the first cloud network, and the method further includes: after receiving an authorization request forwarded by any proxy server, authenticating the proxy server; if the proxy server passes the identity authentication, generating a verification pass message for the authorization request; sending the verification pass message to the proxy server to trigger the proxy server to forward the verification pass message to the device driver component that initiates 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 to which the authorization request points passes the identity authentication.

11. An authorization method, wherein: Applicable to a proxy server deployed in a first cloud network for any other cloud network, the method comprising: after receiving an authorization request initiated by any device driver component loaded in any target instance in the cloud network served by itself, authenticating the target instance; if it is determined that the target instance passes the authentication, forwarding the authorization request to an authorization server deployed in the first cloud network, so as to trigger the authorization server to authenticate the proxy server and generate a verification pass message for the authorization request after determining that the proxy server passes the authentication; The verification pass message sent by the authorization server is forwarded to the device driver component to trigger the device driver component to activate subsequent device driver logic.

12. A computing device, comprising 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 to 11.

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

Images