Cross-account resource calling method based on cloud computing technology, and related device

Abstract

The present application provides a cross-account resource calling method based on cloud computing technology, and a related device. The method is applied to a cloud management system. The cloud management system is used for managing infrastructure where a first service of a first tenant and a second service of a second tenant are configured. The method comprises: a cloud management system acquires an authorization request of a first tenant, wherein the authorization request comprises a tenant identifier of a second tenant, an authorization name, and a specific permission of calling a first service by a second service; the cloud management system creates a specific permission on the basis of the authorization request; the cloud management system acquires a permission acquisition request which is inputted by the second tenant and comprises an authorization name and a tenant identifier of the first tenant; on the basis of the permission acquisition request, the cloud management system configures the second tenant to acquire the specific permission; and when the second tenant configures the second service to call the first service, on the basis of the specific permission, the cloud management system allows the second service to call the first service. In this way, the security of service scheduling in a cross-service cross-account scenario can be improved, and the efficiency of permission configuration and the utilization rate of resources are improved.

Description

A cross-account resource calling method and related equipment based on cloud computing technology

[0001] This application claims priority to Chinese patent application number 202310952497.6, filed with the State Intellectual Property Office on July 31, 2023, entitled “Cross-Account Multi-Service Integration Method,” the entire contents of which are hereby incorporated by reference into this application. Furthermore, this application claims priority to Chinese patent application number 202311697137.2, filed with the State Intellectual Property Office on December 11, 2023, entitled “A Cross-Account Resource Invocation Method and Related Device Based on Cloud Computing Technology,” the entire contents of which are hereby incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of cloud service technology, and in particular to a cross-account resource calling method and related equipment based on cloud computing technology. Background Art

[0003] In cloud serving scenarios, some cloud service platforms offer specific resource sharing services. When other services need to use these resources during business processing, they utilize them across services. For example, a big data service can utilize the container cluster resources provided by a container service through a cross-service approach. This allows multiple services to fully utilize specific resources provided by the cloud service platform through time-division multiplexing.

[0004] Cloud service users manage and use resources through accounts. Accounts are independent of each other, and resources owned by different accounts are isolated from each other. If a user needs to access resources from another account across accounts, authorization from the other account is required.

[0005] Currently, when calling service resources across services and accounts, the authorizing account provides the authorized account with the credentials required to log in to the authorizing account, such as account password, certificate, and passcode. The authorized account then uses this credential information to call resources as the authorizing account. However, providing your own credential information to other accounts carries security risks, potentially leading to misuse of this credential information by other accounts.

[0006] Summary of the Invention

[0007] This application provides a cross-account resource calling method and related equipment based on cloud computing technology, which aims to achieve a high degree of security in the authorization of cross-account and cross-service resource usage permissions through the authorization name and the tenant identifier of the first tenant, and meet the needs of service resource usage in cross-service and cross-account scenarios.

[0008] In a first aspect, the present application provides a method for cross-account resource invocation based on cloud computing technology. This method is applied to a cloud management system. The cloud management system is used to manage infrastructure. The infrastructure includes a first service of a first tenant and a second service of a second tenant. The cloud management system receives an authorization request from the first tenant. The authorization request includes the second tenant's tenant identifier, an authorization name, and specific permissions for the second service to invoke the first service. Based on the received authorization request, the cloud management system creates specific permissions. The cloud management system receives an authorization request from the second tenant, including the authorization name and the first tenant's tenant identifier, and, based on the authorization request, configures the second tenant to obtain specific permissions. This allows cross-service permissions to be obtained using the first tenant's tenant identifier and authorization name without the first tenant revealing their account, password, certificate, or password credentials, thereby improving the security of cross-account and cross-service invocations. Based on the specific permissions, the cloud management system allows the second service to invoke the first service when the second tenant configures the second service to invoke the first service. This enables more secure cross-service and cross-account service invocations, facilitates cross-service and cross-account service configuration, and improves service utilization.

[0009] In one possible implementation, the second tenant includes at least one user. After obtaining the authorization request, the cloud management system configures the second service to create at least one second sub-service corresponding to the at least one user and configures the first service to create at least one first sub-service corresponding to the at least one user. When the user configures the second service to call the first service, at least one second sub-service is allowed to call the corresponding at least one first sub-service. In this way, the second sub-service corresponding to the user can call the first sub-service corresponding to the user. In this way, the authorization of specific permissions in the user dimension can be achieved, avoiding the abuse of permissions by users included in the tenant, configuring the call to the first sub-service corresponding to other users, and effectively avoiding security issues caused by the abuse of permissions.

[0010] In a possible implementation, the first service is a container service.

[0011] In one possible implementation, the specific permissions include container resource permissions. Container resource permissions correspond to container users. Container resource permissions are permissions to use the indicated container resources. This enables the second tenant to call the container service.

[0012] In one possible implementation, the authorization request input by the second tenant also includes the second tenant's credential information. Based on this credential information, the second tenant is configured to switch to the first tenant's identity, allowing the second tenant to obtain specific permissions. This allows the second user's identity to be verified based on the second tenant's credential information, improving the security of cross-account and cross-service calls to the first service's service resources.

[0013] In a second aspect, the present application provides a cross-account resource calling device based on cloud computing technology, characterized in that the device is applied to a cloud management system, the cloud management system is used to manage infrastructure, and the infrastructure is provided with a first service of a first tenant and a second service of a second tenant. The device includes:

[0014] A first acquisition module is configured to acquire an authorization request input by the first tenant, where the authorization request includes the tenant identifier of the second tenant, an authorization name, and a specific permission for the second service to call the first service;

[0015] A creation module, configured to create the specific permission based on the authorization request;

[0016] A second acquisition module is configured to acquire an authorization request input by the second tenant, where the authorization request includes the authorization name and the tenant identifier of the first tenant;

[0017] A first configuration module is configured to configure the second tenant to obtain the specific permission according to the authorization request;

[0018] The second configuration module is configured to allow the second service to call the first service when the second tenant configures the second service to call the first service according to the specific permission.

[0019] In a possible implementation, the second tenant includes at least one user, and the apparatus further includes:

[0020] a third configuration module, configured to configure the second service to create at least one second sub-service corresponding to the at least one user, and configure the first service to create at least one first sub-service corresponding to the at least one user, according to the authorization request;

[0021] The second configuration module is specifically configured to allow the at least one second sub-service to call the corresponding at least one first sub-service when the at least one user configures the second service to call the first service according to the specific permission.

[0022] In a possible implementation, the first service is a container service.

[0023] In a possible implementation, the specific permission includes container resource permission, the container resource permission corresponds to a container user, and the container resource permission is permission to use the container resource.

[0024] In a possible implementation, the authorization request includes credential information of the second tenant, and the first configuration module is specifically used to configure the second tenant to switch identity to the first tenant based on the credential information, so that the second tenant obtains the specific permission.

[0025] In a third aspect, the present application provides a computing device cluster, which includes at least one computing device, each computing device including a processor and a memory; the memory is used to store instructions, and when the computing device cluster is running, the processor in each computing device executes the instructions stored in the memory, so that the computing device cluster executes the cross-account resource call method based on cloud computing technology in the above-mentioned first aspect or any possible implementation of the first aspect. It should be noted that the memory can be integrated into the processor or can be independent of the processor. Each computing device may also include a bus. The processor is connected to the memory via a bus. The memory may include a readable memory and a random access memory.

[0026] In a fourth aspect, the present application provides a computer-readable storage medium, which stores instructions. When the computer-readable storage medium is run on a computing device cluster (the computing device cluster includes at least one computing device), the computing device cluster executes the cross-account resource calling method based on cloud computing technology described in the above-mentioned first aspect or any implementation method of the first aspect.

[0027] In a fifth aspect, the present application provides a computer program product comprising instructions, which, when run on a computing device cluster (the computing device cluster includes at least one computing device), enables the computing device cluster to execute the cross-account resource calling method based on cloud computing technology as described in the above-mentioned first aspect or any implementation method of the first aspect.

[0028] Based on the implementation methods provided in the above aspects, this application can also be further combined to provide more implementation methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] FIG1 is a schematic diagram of a scenario provided by an embodiment of the present application;

[0030] FIG2 is a schematic diagram of an application scenario provided by an embodiment of the present application;

[0031] FIG3 is a flow chart of a cross-account resource calling method based on cloud computing technology provided in an embodiment of the present application;

[0032] FIG4 is a flow chart of another cross-account resource calling method based on cloud computing technology provided in an embodiment of the present application;

[0033] FIG5 is a schematic diagram of a cross-account resource calling method based on cloud computing technology provided in an embodiment of the present application;

[0034] FIG6 is a schematic diagram of the structure of a cross-account resource calling device based on cloud computing technology provided in an embodiment of the present application;

[0035] FIG7 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0036] FIG8 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0037] FIG9 is a schematic diagram of the structure of another computing device cluster provided in an embodiment of the present application. DETAILED DESCRIPTION

[0038] The following will describe the solutions in the embodiments provided in this application in conjunction with the drawings in this application.

[0039] The terms "first," "second," and the like in the specification, claims, and drawings of this application are used to distinguish similar objects, and are not necessarily used to describe a specific order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate. This is merely a way of distinguishing objects with the same attributes in the embodiments of this application.

[0040] First, some technical terms involved in the embodiments of this application are introduced.

[0041] Cloud services refer to internet services that are provided to users through large-scale server clusters using cloud computing technology. These services require no downloading or installation, are readily available online, and offer convenient operation, rich functionality, and low prices. Furthermore, cloud services can provide computing resources and capabilities on demand, resulting in high resource utilization. Cloud services can include cloud hosting services, cloud storage services, and other different types.

[0042] Cloud management systems are used to manage cloud computing infrastructure.

[0043] A container is a running instance created from a Docker image. A single node can run multiple containers. A container is essentially a process, but unlike processes that execute directly on the host, container processes run in their own independent namespace.

[0044] The MapReduce Service provides a highly reliable, secure, and easy-to-use operations and maintenance platform, offering large-scale data storage and analysis capabilities to address the data storage and processing needs of major enterprises. Users can independently apply for and utilize managed Hadoop, Spark, HBase, and Hive services to quickly create clusters on their hosts, providing batch data storage and computing capabilities for massive amounts of data without requiring high real-time performance.

[0045] Cloud Container Engine (CCE) is used to provide highly reliable and high-performance enterprise-level container application management services, support native applications and tools from the Kubernetes community, and simplify the establishment of automated container runtime environments on the cloud.

[0046] In the process of users using cloud services to handle business, cross-service and cross-account resource calls will be involved. Taking big data services and container services as an example, see Figure 1, which is a scenario diagram provided by an embodiment of the present application. Account B of the big data service needs to obtain container cluster resources from the container service. Account A of the container service authorizes Account B of the big data service and provides Account B of the big data service with credential information such as Account A's Secret Access Key (SK), Account Key (AK), password (token) or certificate. Account B uses Account A's credential information to use Account A's container cluster resources in the container service.

[0047] However, passing account credentials carries a high security risk. For example, Account B could misuse Account A's credentials. For example, Account B could exceed its authorized permissions to access Account A's resources. Furthermore, the expiration date of Account A's credentials is difficult to control. Account B could continue to use Account A's credentials before they become invalid, potentially unauthorizedly accessing resources.

[0048] Based on this, an embodiment of the present application provides a cross-account resource call method based on cloud computing technology. The method is applied to a cloud management system, which is used to manage infrastructure, on which a first service of a first tenant and a second service of a second tenant are set. The cloud management system obtains an authorization request from the first tenant. The authorization request includes the tenant identifier of the second tenant, the authorization name, and the specific permission for the second service to call the first service. Based on the authorization request, the cloud management system creates specific permissions. The cloud management system obtains an authorization request input by the second tenant, including the authorization name and the tenant identifier of the first tenant, and configures the second tenant to obtain specific permissions based on the authorization request. Based on the specific permissions, when the second tenant configures the second service to call the first service, the cloud management system allows the second service to call the first service. In this way, there is no need to use the credential information of the first tenant's service account to implement resource calls, and authorization in cross-service and cross-account scenarios with a higher degree of security can be achieved. It can also improve the efficiency of configuring permissions in cross-service and cross-account scenarios and improve the utilization rate of service resources.

[0049] The embodiments of the present application do not limit the application scenarios of the cross-account resource call method based on cloud computing technology. As some examples, Figure 2 is a schematic diagram of an application scenario provided by the embodiments of the present application. The cross-account resource call method based on cloud computing technology provided by the embodiments of the present application can be applied to a cloud management system. The cloud management system is used to manage infrastructure. The infrastructure is provided with a MapReduce service and a CCE service. An authorization request is obtained from the first tenant of the CCE service. That is, the authorization request is sent by the first tenant using account C. The authorization request includes the tenant identifier of the second tenant of the MapReduce service (account D), the authorization name, and the specific permissions for the MapReduce service to call the CCE service. Based on the authorization request, the cloud management system creates specific permissions. The cloud management system obtains an authorization request input by the second tenant. The authorization request includes the authorization name and the tenant identifier of the first tenant, that is, account C. Based on the authorization request, the cloud management system configures the second tenant to obtain specific permissions. When the second tenant configures the MapReduce service to call the CCE service, the MapReduce service is allowed to call the CCE service based on the specific permissions.

[0050] It should be noted that the application scenario shown in Figure 2 above is only an example. The cross-account resource calling method based on cloud computing technology provided in this application can be applied to other cross-service and cross-account service resource calling scenarios. The application scenario of the cross-account resource calling method based on cloud computing technology provided in the embodiment of this application is not limited to the application scenario shown in Figure 2.

[0051] Next, various non-limiting specific implementations of the cloud computing-based cross-account resource invocation method provided in this application are described in detail. See Figure 3, which is a flow chart illustrating a cloud computing-based cross-account resource invocation method provided in an embodiment of this application. This method can be applied to the cloud management system in the scenario shown in Figure 2 above. The method includes steps S301-S309.

[0052] S301: Obtaining the authorization request of the first tenant.

[0053] The first tenant is a tenant of the first service. The first tenant has the right to call the service resources of the first service. The first tenant can trigger an authorization request for the second tenant.

[0054] The authorization request includes the second tenant's tenant ID, the authorization name, and the specific permission for the second service to invoke the first service. The second tenant is the tenant of the second service. The second tenant's tenant ID is, for example, the second tenant's tenant account ID. The first tenant's tenant ID is different from the second tenant's tenant ID. The authorization name is used to identify the specific permission.

[0055] In some possible implementations, the specific permission authorized by the first tenant to the second tenant does not exceed the first tenant's permission to use the service resources of the first service.

[0056] As an example, in the application scenario shown in FIG2 , the first service is a container service. The embodiment of the present application does not limit the specific type of service resources of the container service. The container service is, for example, a Kubernetes service.

[0057] In a possible implementation, the specific permission includes container resource permission, which is permission for the second tenant to use the container resources.

[0058] As an example, container resource permissions can be granted by the administrator of the container service to the container user. Specific permissions correspond to container users. Taking the Kubernetes service as an example, container resource permissions can be permissions created by the Kubernetes administrator for the container user using role-based access control (RBAC), corresponding to the container user. Container resource permissions, for example, are access permissions for the global namespace or access permissions for a specified namespace. In this way, the second tenant can configure the second service to call the container service according to the container resource permissions.

[0059] S303: Create specific permissions based on the authorization request.

[0060] A specific permission is created based on the obtained authorization request. The created specific permission is the permission for the second service to call the first service. In one possible implementation, a delegation is created based on the authorization request. The delegation is a collection of permissions, including the specific permission.

[0061] S305: Acquire an authorization request input by the second tenant, where the authorization request includes an authorization name and a tenant identifier of the first tenant.

[0062] The second tenant's authorization request is used to trigger the configuration of the second tenant to obtain specific permissions. The second tenant generates an authorization request by entering the first tenant's tenant ID and authorization name. For example, the second tenant enters the first tenant's tenant ID and authorization name through the console user interface (Console UI) or application program interface (API) to trigger the generation of the authorization request.

[0063] The authorization request includes the tenant ID of the first tenant and the authorization name. The tenant ID of the first tenant is, for example, the account ID of the first tenant. The authorization name is used to identify a specific permission. For example, the specific permission created is a delegation. The authorization name is the delegation name.

[0064] Based on the tenant identifier of the first tenant, the first service can be called using the identity of the tenant identifier of the first tenant. Based on the authorization name, a specific permission can be determined, so that the first service can be called within the scope of the specific permission.

[0065] In one possible implementation, the authorization name is used to query for specific permissions. For example, the cloud management system creates multiple delegations and uses the authorization name (i.e., delegation name) included in the authorization request to query the delegation corresponding to the delegation name.

[0066] S307: According to the authorization request, configure the second tenant to obtain specific permissions.

[0067] The authorization request can be used to determine the specific permission identified by the authorization name and the tenant ID of the first tenant. Specific permissions are configured for the second tenant, so that the second tenant can use the specific permissions to configure the second service to call the first service, thereby achieving authorization of the specific permissions.

[0068] It should be noted that, in a possible implementation, the authorization request also includes the credential information of the second tenant. The identity of the second tenant can be verified using the credential information of the second tenant. Based on the credential information of the second tenant, the second tenant is configured to switch its identity to the first tenant, so that the second tenant obtains specific permissions. The embodiment of the present application does not limit the method of switching identities. As an example, the identity of the second tenant is switched based on the unified identity authentication (Identity and Access Management, IAM) service. In this way, the second tenant can obtain specific permissions based on the credential information of the second tenant, thereby improving the security of cross-service and cross-account service resource calls.

[0069] S309: According to the specific permission, when the second tenant configures the second service to call the first service, the second service is allowed to call the first service.

[0070] For the second tenant who obtains specific permissions, when configuring the second service to call the first service, the cloud management system allows the second service to call the first service. It should be noted that the permission scope of the second tenant to configure the second service to call the first service falls within the permission scope of specific permissions.

[0071] The embodiments of the present application do not limit the triggering method for the second tenant to configure the second service to call the first service. As an example, when the second service is used to process the second tenant's business, upon detecting that the service resources of the first service need to be used, the second service is automatically triggered to call the first service. As another example, a configuration request triggered by the second tenant to configure the second service to call the first service is obtained. Based on the configuration request, the second service is configured to call the first service.

[0072] Based on the relevant contents of S301-S309 above, it can be known that by utilizing the tenant identifier, authorization name and specific permissions of the second tenant, it is possible to create specific permissions configured for the second tenant and realize cross-account and cross-service authorization. After the second tenant obtains specific permissions based on the authorization request including the authorization name and the tenant identifier of the first tenant, it can configure the second service to call the first service based on the specific permissions. On the one hand, this can avoid the transmission of credential information such as passwords and certificates, reduce the risk of cross-account service interaction, and realize authorization in cross-service and cross-account scenarios with a higher degree of security. On the other hand, it can improve the efficiency of configuring cross-service and cross-account authorization, meet the needs of service resource usage in cross-service and cross-account scenarios, and improve the flexibility of service resource management and service resource utilization.

[0073] In some possible implementation scenarios, the second tenant includes at least one user. In addition to the above steps, see Figure 4, which is a flow chart of another cross-account resource calling method based on cloud computing technology provided by an embodiment of the present application. The method also includes the following steps:

[0074] S308: According to the authorization request, configure the second service to create at least one second sub-service corresponding to the at least one user, and configure the first service to create at least one first sub-service corresponding to the at least one user.

[0075] In the case where the second tenant includes at least one user, the specific permission can be a permission authorized in the user dimension. According to the authorization request input by the second tenant, the second service is configured to create at least one second sub-service corresponding to at least one user included in the second tenant, and the first service is configured to create at least one first sub-service corresponding to at least one user. The second sub-service belongs to the second service and is created within the scope of the second service managed by the second tenant. The first sub-service belongs to the first service and is created within the scope of the first service that can be called within the specific permission obtained by the second tenant based on the authorization request configuration.

[0076] The configured first and second sub-services both correspond to users included in the second tenant. This allows for user-level service call configuration, adheres to the principle of least authorization, and implements fine-grained authorization.

[0077] Further, S309: according to the specific permission, when the second tenant configures the second service to call the first service, allowing the second service to call the first service specifically includes:

[0078] According to the specific permission, when at least one user configures a second service to call a first service, at least one second sub-service is allowed to call the corresponding at least one first sub-service.

[0079] When a user of the second tenant configures a second service to call the first service, the second sub-service corresponding to the user is allowed to call the first sub-service corresponding to the user based on specific permissions. This allows the user's first sub-service to be called, preventing users of the same tenant from unauthorizedly calling the first sub-services of other users, thus improving authorization security.

[0080] As an example, see Figure 5, which is a schematic diagram of a cross-account resource invocation method based on cloud computing technology provided in an embodiment of the present application. The first service is a CCE service, and the tenant identifier of the first tenant is account x. The second service is a MapReduce service, and the tenant identifier of the second tenant is account y. The second tenant includes user 1, user 2, and user 3.

[0081] The first tenant logs in to account x and sends an authorization request to the cloud management system. The authorization request includes the tenant ID of the second tenant, namely "account y", the authorization name, namely the delegation number, and the specific permission for the MapReduce service to call the CCE service.

[0082] As an example, the first tenant sends a first authorization request, a second authorization request, and a third authorization request to the cloud management system. The first authorization request includes account y, CCE_X_1, and user 1's specific permissions. CCE_X_1 is the delegation number. The second authorization request includes account y, CCE_X_2, and user 2's specific permissions. CCE_X_2 is the delegation number. The third authorization request includes account y, CCE_X_3, and user 3's specific permissions. CCE_X_3 is the delegation number.

[0083] The cloud management system receives the first, second, and third authorization requests and creates delegations CCE_X_1, CCE_X_2, and CCE_X_3. Delegation CCE_X_1 includes the specific permissions of user 1. Delegation CCE_X_2 includes the specific permissions of user 2. Delegation CCE_X_3 includes the specific permissions of user 3.

[0084] The cloud management system receives the authorization request from the second tenant. For example, User 1 enters an authorization request that includes CCE_X_1 and account number x. The cloud management system configures User 1 to obtain specific permissions based on the first authorization request. The cloud management system configures the MapReduce service to create a subservice corresponding to User 1, MRS_1, and configures the CCE service to create a subservice corresponding to User 1, CCE_A. When User 1 configures MRS to call the CCE service, the cloud management system allows MRS1 to call CCE_A.

[0085] In addition, the specific permissions included in the first authorization request include container resource permissions. Container resource permissions are permissions that Kubernetes administrators create for container users based on RBAC. This allows User 1 to use MRS_1 to call CCE_A to create a virtual cluster, create a namespace within CCE_A's cluster, and run workloads on the CCE cluster.

[0086] The cloud management system also receives the authorization request for CCE_X_2 and account x entered by user 2. The cloud management system configures user 2 to obtain specific permissions based on the second authorization request. The cloud management system configures the MapReduce service to create a subservice corresponding to user 2, MRS_2, and the CCE service to create a subservice corresponding to user 2, CCE_B. When user 2 configures MRS to call the CCE service, it allows MRS_2 to call CCE_B.

[0087] The cloud management system also receives the authorization request for CCE_X_3 and account x entered by user 3. The cloud management system configures user 3 to obtain specific permissions based on the third authorization request. The cloud management system also configures the MapReduce service to create a subservice corresponding to user 3, MRS_3, and the CCE service to create a subservice corresponding to user 3, CCE_C. When user 2 configures MRS to call the CCE service, it allows MRS_2 to call CCE_C.

[0088] It is worth noting that in this solution, the MapReduce service or CCE service can create sub-services by making logical distinctions within the service through different namespaces to achieve the division of sub-services.

[0089] Based on this, when there are multiple users under a tenant, by configuring the first service or the second service to create sub-services corresponding to the users, when different users are authorized to request to call the service, they can call the sub-services separately, avoiding the mixing of resources, thereby improving the security of different users calling across services and ensuring high availability and high security of resources.

[0090] This application also provides a cross-account resource invocation device based on cloud computing technology. This cross-account resource invocation device based on cloud computing technology is applied to a cloud management system. The cloud management system is used to manage infrastructure. The infrastructure is provided with a first service of a first tenant and a second service of a second tenant. The device, as shown in FIG6 , includes:

[0091] A first acquisition module 601 is configured to acquire an authorization request input by the first tenant, where the authorization request includes the tenant identifier of the second tenant, an authorization name, and a specific permission for the second service to call the first service;

[0092] A creation module 602, configured to create the specific permission based on the authorization request;

[0093] A second obtaining module 603 is configured to obtain an authorization request input by the second tenant, where the authorization request includes the authorization name and the tenant identifier of the first tenant;

[0094] A first configuration module 604 is configured to configure the second tenant to obtain the specific permission according to the authorization request;

[0095] The second configuration module 605 is configured to allow the second service to call the first service when the second tenant configures the second service to call the first service according to the specific permission.

[0096] In a possible implementation, the second tenant includes at least one user, and the apparatus further includes:

[0097] a third configuration module, configured to configure the second service to create at least one second sub-service corresponding to the at least one user, and configure the first service to create at least one first sub-service corresponding to the at least one user, according to the authorization request;

[0098] The second configuration module is specifically configured to allow the at least one second sub-service to call the corresponding at least one first sub-service when the at least one user configures the second service to call the first service according to the specific permission.

[0099] In a possible implementation, the first service is a container service.

[0100] In a possible implementation, the specific permission includes container resource permission, the container resource permission corresponds to a container user, and the container resource permission is permission to use the container resource.

[0101] In a possible implementation, the authorization request includes credential information of the second tenant, and the first configuration module is specifically used to configure the second tenant to switch identity to the first tenant based on the credential information, so that the second tenant obtains the specific permission.

[0102] The first acquisition module 601, the creation module 602, the second acquisition module 603, the first configuration module 604, and the second configuration module 605 can all be implemented via software or hardware. For example, the implementation of the first acquisition module 601 will be described below using the first acquisition module 601 as an example. Similarly, the implementation of the creation module 602, the second acquisition module 603, the first configuration module 604, and the second configuration module 605 can refer to the implementation of the first acquisition module 601.

[0103] As an example of a software functional unit, the first acquisition module 601 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the first acquisition module 601 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Typically, a region may include multiple AZs.

[0104] Similarly, the multiple hosts / virtual machines / containers used to run the code can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0105] As an example of a hardware functional unit, the first acquisition module 601 may include at least one computing device, such as a server. Alternatively, the first acquisition module 601 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0106] The multiple computing devices included in the first acquisition module 601 can be distributed in the same region or in different regions. The multiple computing devices included in the first acquisition module 601 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the first acquisition module 601 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0107] It should be noted that, in other embodiments, the first acquisition module 601 can be used to execute any step in the cross-account resource calling method based on cloud computing technology, the creation module 602 can be used to execute any step in the cross-account resource calling method based on cloud computing technology, the second acquisition module 603 can be used to execute any step in the cross-account resource calling method based on cloud computing technology, the first configuration module 604 can be used to execute any step in the cross-account resource calling method based on cloud computing technology, and the second configuration module 605 can be used to execute any step in the cross-account resource calling method based on cloud computing technology. The steps implemented by the first acquisition module 601, the creation module 602, the second acquisition module 603, the first configuration module 604, and the second configuration module 605 can be specified as needed. The first acquisition module 601, the creation module 602, the second acquisition module 603, the first configuration module 604, and the second configuration module 605 respectively implement different steps in the cross-account resource calling method based on cloud computing technology to realize all the functions of the cross-account resource calling device based on cloud computing technology.

[0108] This application also provides a computing device 700. As shown in Figure 7, computing device 700 includes a bus 702, a processor 704, a memory 706, and a communication interface 708. Processor 704, memory 706, and communication interface 708 communicate with each other via bus 702. Computing device 700 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in computing device 700.

[0109] Bus 702 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG7 illustrates a single bus line, but this does not imply a single bus or type of bus. Bus 702 may include a path for transmitting information between various components of computing device 700 (e.g., memory 706, processor 704, and communication interface 708).

[0110] The processor 704 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0111] The memory 706 may include volatile memory, such as random access memory (RAM). The processor 704 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0112] Memory 706 stores executable program code, and processor 704 executes the executable program code to implement the functions of the aforementioned first acquisition module 601, creation module 602, second acquisition module 603, first configuration module 604, and second configuration module 605, thereby implementing the cross-account resource call method based on cloud computing technology. In other words, memory 706 stores instructions for executing the cross-account resource call method based on cloud computing technology.

[0113] The communication interface 708 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 700 and other devices or a communication network.

[0114] Embodiments of the present application also provide a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0115] As shown in Figure 8, the computing device cluster includes at least one computing device 700. The memory 706 in one or more computing devices 700 in the computing device cluster may store the same instructions for executing the cross-account resource calling method based on cloud computing technology.

[0116] In some possible implementations, the memory 706 of one or more computing devices 700 in the computing device cluster may also store partial instructions for executing the cross-account resource call method based on cloud computing technology. In other words, the combination of one or more computing devices 700 can jointly execute the instructions for executing the cross-account resource call method based on cloud computing technology.

[0117] It should be noted that the memory 706 in different computing devices 700 in the computing device cluster can store different instructions, each for executing part of the functions of the cross-account resource invocation apparatus based on cloud computing technology. In other words, the instructions stored in the memory 706 in different computing devices 700 can implement the functions of one or more modules among the first acquisition module 601, the creation module 602, the second acquisition module 603, the first configuration module 604, and the second configuration module 605.

[0118] In some possible implementations, one or more computing devices in a computing device cluster may be connected via a network. The network may be a wide area network (WAN) or a local area network (LAN), among others. FIG. 9 illustrates a possible implementation. As shown in FIG. 9 , two computing devices 700A and 700B are connected via a network. Specifically, the network is connected via a communication interface in each computing device. In this type of possible implementation, the memory 706 in the computing device 700A stores instructions for executing the functions of the first acquisition module 601 and the creation module 602. Simultaneously, the memory 706 in the computing device 700B stores instructions for executing the functions of the second acquisition module 603, the first configuration module 604, and the second configuration module 605.

[0119] The connection method between the computing device clusters shown in Figure 9 can be based on the needs of the cross-account resource calling method based on cloud computing technology provided in this application, so it is considered to entrust the functions implemented by the second acquisition module 603, the first configuration module 604 and the second configuration module 605 to the computing device 700B for execution.

[0120] It should be understood that the functionality of the computing device 700A shown in FIG9 may also be implemented by multiple computing devices 700. Similarly, the functionality of the computing device 700B may also be implemented by multiple computing devices 700.

[0121] The present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes a cross-account resource call method based on cloud computing technology.

[0122] The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute a cross-account resource call method based on cloud computing technology.

[0123] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the protection scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A cross-account resource calling method based on cloud computing technology, characterized in that: The method is applied to a cloud management system, the cloud management system is used to manage an infrastructure, a first service of a first tenant and a second service of a second tenant are arranged on the infrastructure, the method comprises: Obtaining an authorization request input by the first tenant, the authorization request including the tenant identifier of the second tenant, an authorization name, and a specific permission for the second service to call the first service; Creating the specific permission based on the authorization request; Obtaining an authorization request input by the second tenant, where the authorization request includes the authorization name and the tenant identifier of the first tenant; According to the authorization request, configuring the second tenant to obtain the specific permission; According to the specific permission, when the second tenant configures the second service to call the first service, the second service is allowed to call the first service.

2. The method according to claim 1, characterized in that The second tenant includes at least one user, and the method further includes: According to the authorization request, configure the second service to create at least one second sub-service corresponding to the at least one user, and configure the first service to create at least one first sub-service corresponding to the at least one user; The allowing the second service to call the first service when the second tenant configures the second service to call the first service according to the specific permission includes: According to the specific permission, when the at least one user configures the second service to call the first service, the at least one second sub-service is allowed to call the corresponding at least one first sub-service.

3. The method according to claim 1 or 2, characterized in that: The first service is a container service.

4. The method according to claim 3, characterized in that The specific permissions include container resource permissions, the container resource permissions correspond to container users, and the container resource permissions are permissions for using container resources.

5. The method according to any one of claims 1 to 4, characterized in that: The authorization request includes the credential information of the second tenant, and configuring the second tenant to obtain the specific permission based on the authorization request includes: configuring the second tenant to switch identity to the first tenant based on the credential information so that the second tenant obtains the specific permission.

6. A cross-account resource calling device based on cloud computing technology, characterized in that: The device is applied to a cloud management system, the cloud management system is used to manage infrastructure, the infrastructure is provided with a first service of a first tenant and a second service of a second tenant, and the device includes: A first acquisition module is used to acquire an authorization request input by the first tenant, where the authorization request includes a tenant identifier of the second tenant, an authorization name, and a specific permission for the second service to call the first service; A creation module, used to create the specific permission based on the authorization request; A second acquisition module is used to acquire an authorization request input by the second tenant, where the authorization request includes the authorization name and the tenant identifier of the first tenant; A first configuration module, configured to configure the second tenant to obtain the specific permission according to the authorization request; The second configuration module is used to allow the second service to call the first service when the second tenant configures the second service to call the first service according to the specific permission.

7. The device according to claim 6, characterized in that The second tenant includes at least one user, and the device further includes: a third configuration module, configured to configure the second service to create at least one second sub-service corresponding to the at least one user, and to configure the first service to create at least one first sub-service corresponding to the at least one user, according to the authorization request; The second configuration module is specifically configured to allow the at least one second sub-service to call the corresponding at least one first sub-service when the at least one user configures the second service to call the first service according to the specific permission.

8. The device according to claim 6 or 7, characterized in that The first service is a container service.

9. The device according to claim 8, characterized in that The specific permissions include container resource permissions, the container resource permissions correspond to container users, and the container resource permissions are permissions for using container resources.

10. The device according to any one of claims 6 to 9, characterized in that: The authorization request includes the credential information of the second tenant, and the first configuration module is specifically configured to configure the second tenant to switch identity to the first tenant according to the credential information, so that the second tenant obtains the specific authority.

11. A computing device cluster, characterized in that: comprising at least one computing device, each computing device comprising a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 5.

12. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device cluster, the computing device cluster executes the method according to any one of claims 1 to 5.

13. A computer-readable storage medium, characterized in that: The method comprises computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster performs the method according to any one of claims 1 to 5.

Images