Multi-account sharing method for cloud service, device, storage medium, and program product

Abstract

Provided in the embodiments of the present disclosure are a multi-account sharing method for a cloud service, a device, a storage medium, and a program product. For a target cloud service for which a first cloud account has ownership, a binding relationship between the target cloud service and a second cloud account associated with the first cloud account can be established, so as to give the second cloud account the right to use the target cloud service. In this way, the second cloud account subsequently uses the target cloud service on the basis of the binding relationship and within the scope of permission enjoyed by the second cloud account. Thus, the resource sharing of a target cloud service between multiple cloud accounts is realized, and the target cloud service is no longer used by only a single cloud account, thereby reducing the use costs of the target cloud service, and improving the utilization rate of the target cloud service. In particular, for the resource sharing of KMS instances of enterprise users between multiple accounts, the problems of excessively high use costs and low utilization rate of the KMS instances purchased by the enterprise users in single account use can be solved.

Description

[0001] This disclosure claims priority to Chinese patent application No. 202410324066.X, filed with the China Patent Office on March 20, 2024, and entitled "Multi-Account Sharing Method, Device, Storage Medium, and Program Product for Cloud Services." The entire contents of this application are incorporated herein by reference. Technical Field: This disclosure relates to the field of cloud computing, and more particularly to a multi-account sharing method, device, storage medium, and program product for cloud services. Background: Enterprise users typically register multiple cloud accounts on cloud service platforms and subscribe to various cloud services provided by these cloud accounts. Key Management Service (KMS) is a cloud service provided by cloud service platforms that helps users manage keys. In practice, enterprise users subscribe to a KMS instance using a cloud account. The cloud account subscribing to the KMS instance can use the KMS instance to create and update keys, encrypt data using keys obtained from the KMS instance, and reduce key management and maintenance costs. Currently, cloud services like KMS instances suffer from high usage costs and low utilization rates. SUMMARY Various aspects of the present disclosure provide a method, device, storage medium, and program product for multi-account sharing in cloud services to address these issues. An embodiment of the present disclosure provides a multi-account sharing method for a cloud service, comprising: receiving a binding request for a target cloud service, the binding request including a second cloud account, the target cloud service being a cloud service owned by a first cloud account; establishing a binding relationship between the second cloud account and the target cloud service, if a set association relationship exists between the second cloud account and the first cloud account, so as to share the target cloud service with the second cloud account within a scope of permissions enjoyed by the second cloud account; and responding to a service request from the second cloud account, controlling the target cloud service to provide the target service to the second cloud account within the scope of permissions enjoyed by the second cloud account based on the binding relationship between the second cloud account and the target cloud service.Embodiments of the present disclosure provide a method for sharing a key management service instance with multiple accounts, comprising: receiving a binding request for the key management service instance, the binding request including a second cloud account, the key management service instance being a cloud service owned by a first cloud account; obtaining, from resource specification information of the key management service instance, the total number of resource objects that the key management service instance can create, if the second cloud account has an established association with the first cloud account; establishing a binding relationship between the key management service instance and the second cloud account to share the key management service instance with the second cloud account if the number of valid resource objects already created by the key management service instance is less than the total number of resource objects that the key management service instance can create; and responding to a service request from the second cloud account, controlling the key management service instance to provide resource object management services to the second cloud account within the scope of permissions granted to the second cloud account based on the binding relationship between the second cloud account and the key management service instance. Embodiments of the present disclosure provide a computer device, comprising: a memory and a processor; the memory storing a computer program; and the processor coupled to the memory for executing the computer program to perform steps in the method for sharing a cloud service with multiple accounts or the method for sharing a key management service instance with multiple accounts. Embodiments of the present disclosure provide a computer-readable storage medium storing a computer program. When executed by a processor, the computer program causes the processor to implement the steps of a multi-account sharing method for a cloud service or a multi-account sharing method for a key management service instance. Embodiments of the present disclosure provide a computer program product, including a computer program / instructions. When executed by a processor, the computer program / instructions cause the processor to implement the steps of a multi-account sharing method for a cloud service or a multi-account sharing method for a key management service instance. In embodiments of the present disclosure, for a target cloud service owned by a first cloud account, a binding relationship can be established between the target cloud service and a second cloud account associated with the first cloud account, thereby granting the second cloud account the right to use the target cloud service. Subsequently, based on the binding relationship, the second cloud account can use the target cloud service within the scope of the second cloud account's permissions. This enables resource sharing of the target cloud service among multiple cloud accounts, eliminating the need for the target cloud service to be used solely by a single cloud account. This reduces the cost of using the target cloud service and increases its utilization rate. In particular, resource sharing among multiple accounts of KMS instances for enterprise users can solve the problem of high cost and low usage rate for enterprise users purchasing KMS instances for a single account. It can also solve the usage permission problem of key objects or credential objects in multi-account scenarios.BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings described herein are intended to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The exemplary embodiments of the present disclosure and their descriptions are intended to explain the present disclosure and do not constitute undue limitations thereon. In the accompanying drawings: Figure 1 is a flowchart of a multi-account sharing method for a cloud service provided in an embodiment of the present disclosure; Figure 2 is an exemplary resource directory provided in an embodiment of the present disclosure; Figure 3 is a flowchart of a multi-account sharing method for a key management service instance provided in an embodiment of the present disclosure; Figure 4 is a schematic diagram of an exemplary sharing of usage rights provided in an embodiment of the present disclosure; Figure 5 is a schematic diagram of an exemplary cancellation of shared usage rights provided in an embodiment of the present disclosure; Figure 6 is a schematic diagram of an exemplary creation of a credential object provided in an embodiment of the present disclosure; Figure 7 is a schematic diagram of an exemplary updating of a credential object provided in an embodiment of the present disclosure; Figure 8 is a schematic diagram of an exemplary acquisition of a credential object provided in an embodiment of the present disclosure; Figure 9 is a schematic diagram of the structure of a multi-account sharing apparatus for a cloud service provided in an embodiment of the present disclosure; and Figure 10 is a schematic diagram of the structure of a computer device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION To further clarify the objectives, technical solutions, and advantages of the present disclosure, the technical solutions of the present disclosure will be described clearly and completely below in conjunction with the specific embodiments of the present disclosure and the corresponding drawings. Obviously, the described embodiments are only a portion of the embodiments of this disclosure, and not all of them. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure. It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display) involved in this disclosure are all authorized by the user or fully authorized by all parties. The collection, use, and processing of relevant data must comply with relevant laws, regulations, and standards in the relevant region, and corresponding operation portals are provided for users to choose to authorize or reject. Furthermore, the various models involved in this disclosure (including but not limited to language models or large models) comply with relevant laws and standards. In the embodiments of this disclosure, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the access relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can represent three situations: A exists alone, A and B exist at the same time, and B exists alone. A and B can be singular or plural.In the text descriptions of this disclosure, the character " / " generally indicates that the preceding and following objects are in an "or" relationship. Furthermore, in the embodiments of this disclosure, "first," "second," "third," and so on are merely used to distinguish the contents of different objects and have no other special meanings. Enterprise users typically register multiple cloud accounts on a cloud service platform and subscribe to various cloud services provided by the cloud service platform under these cloud accounts. Key Management Service (KMS) is a cloud service provided by the cloud service platform that helps users manage keys. In practice, an enterprise user subscribes to a KMS instance using a cloud account. The cloud account subscribed to the KMS instance can use the KMS instance to create and update keys, and encrypt data using keys obtained from the KMS instance, reducing key management and maintenance costs. Currently, cloud services such as KMS instances suffer from high usage costs and low utilization rates. To address this issue, embodiments of this disclosure provide a method, device, storage medium, and program product for multi-account sharing of cloud services. For a target cloud service owned by a first cloud account, a binding relationship can be established between the target cloud service and a second cloud account associated with the first cloud account, thereby granting the second cloud account usage rights to the target cloud service. This allows the second cloud account to subsequently use the target cloud service within the scope of the second cloud account's permissions based on the binding relationship. This enables resource sharing of the target cloud service across multiple cloud accounts, eliminating the need for a single cloud account to use the service. This reduces the cost of using the target cloud service and increases its utilization rate. In particular, resource sharing of KMS instances across multiple accounts for enterprise users can address the high cost of purchasing KMS instances for a single account and low utilization rates. It can also address usage rights issues for key objects or credential objects in multi-account scenarios. The following detailed description of the technical solutions provided by various embodiments of the present disclosure is provided in conjunction with the accompanying drawings. Figure 1 is a flowchart of a multi-account sharing method for cloud services provided by an embodiment of the present disclosure. Referring to Figure 1 , the method may include the following steps:

[0002] 101. Receive a binding request for a target cloud service, where the binding request includes a second cloud account. The target cloud service is a cloud service owned by a first cloud account.

[0003] 102. When the second cloud account and the first cloud account have a set association relationship, establish a binding relationship between the second cloud account and the target cloud service, so as to share the target cloud service with the second cloud account within the scope of the second cloud account's permissions.

[0004] 103. In response to the service request from the second cloud account, based on the binding relationship between the second cloud account and the target cloud service, control the target cloud service to provide the target service to the second cloud account within the scope of the second cloud account's permissions. In actual applications, cloud service platforms provide a variety of cloud services, such as KMS, cloud servers, cloud storage (e.g., cloud disks), and cloud security. Before using cloud services, users must first register a cloud account on the cloud service platform. The cloud account serves as a unique identifier for users to access cloud services provided by the cloud service platform. After registering a cloud account, users can purchase cloud services on demand through the cloud service platform using the cloud account. The user's cloud account owns the purchased cloud services, and the user can subsequently use the cloud services owned by the cloud account. For example, a cloud service platform provides KMS instances of various specifications for users to purchase on demand. For example, the KMS instance purchased under a user's cloud account has the following specifications: 1000 key objects allowed, 100 credential objects allowed. Another example is that a cloud service platform provides cloud server instances of various specifications for users to purchase on demand. For example, the cloud server instances purchased under a user's cloud account have the following specifications: 8-core 32GB, 16-core 32GB, 32-core 96GB, and so on. 8-core 32GB indicates 8 vCPU (virtual central processing unit) cores and 32GB of memory; 16-core 32GB indicates 16 vCPU cores and 32GB of memory; and 32-core 96GB indicates 32 vCPU cores and 96GB of memory. Another example is that a cloud service platform provides cloud disk instances of various specifications for users to purchase on demand. For example, the cloud disk instances purchased by a user's cloud account have the following specifications: 500GB, 2TB (terabyte), and 10TB. In this embodiment, cloud services owned by a cloud account can be shared with other cloud accounts through resource sharing. Other cloud accounts do not own the cloud services, only have usage rights. For ease of understanding and distinction, the cloud service owned by the first cloud account is referred to as the target cloud service. The first cloud account is the cloud account that owns the target cloud service; the second cloud account needs to be granted the cloud account that has usage rights to the target cloud service. For example, target cloud services may include, but are not limited to, KMS, cloud servers, cloud storage, and cloud security.In this embodiment, when a second cloud account needs to be granted usage rights for a target cloud service, a binding request to the target cloud service may be triggered. The binding request indicates the establishment of a binding relationship between the second cloud account and the target cloud service. The binding request may include the second cloud account and the identifier of the target cloud service. Establishing a binding relationship between the second cloud account and the identifier of the target cloud service completes the establishment of the binding relationship between the second cloud account and the target cloud service. In this embodiment, after the binding request is triggered, it may be determined whether a set association relationship exists between the second cloud account and the first cloud account. If a set association relationship exists between the second cloud account and the first cloud account, the binding relationship between the second cloud account and the target cloud service is established. However, if a set association relationship does not exist between the second cloud account and the first cloud account, the binding relationship between the second cloud account and the target cloud service is rejected. In other words, a target cloud service owned by a first cloud account can be shared with a second cloud account associated with the first cloud account. Specifically, the second cloud account associated with the first cloud account can be granted the right to use the target cloud service; a second cloud account not associated with the first cloud account cannot be granted the right to use the target cloud service, thereby improving the security of resource sharing. In this embodiment, the association between the second cloud account and the first cloud account includes, but is not limited to: the second cloud account and the first cloud account are different cloud accounts registered by the same user on the cloud service platform; or the second cloud account and the first cloud account are different cloud accounts registered by different users with a business relationship on the cloud service platform; or the second cloud account and the first cloud account are different cloud accounts in the same resource directory, where the resource directory manages associated cloud accounts. For example, an enterprise user creates multiple cloud accounts while using the cloud service platform. The enterprise user uses the resource directory to organize and centrally manage these multiple cloud accounts, enabling resource sharing. Taking the resource directory shown in Figure 2 as an example, the enterprise user's cloud account A1 is located under the resource folder of department A. Under the resource folder of department B, an enterprise user has cloud accounts B1 and B2. The enterprise user's management account, cloud accounts A1, B1, and B2 are organized in a resource directory. Cloud account A1 has purchased a KMS instance, meaning it owns the KMS instance and is the resource owner of the KMS instance. Cloud account A1 shares the KMS instance with cloud accounts B1 and B2, meaning they have usage rights to the KMS instance purchased by cloud account A1 and are resource users of the KMS instance.In this way, an enterprise user's multiple cloud accounts can share a KMS instance under a cloud account with one or more other cloud accounts through resource sharing. In some optional embodiments, the target cloud service can be a cloud service that provides resource object management services for cloud accounts, for example, a KMS instance. A KMS instance can provide key object management services. Key objects typically include a key name and a key value, which are used for data encryption. A KMS instance can also provide credential object management services. A credential object is a set of information used by a user to prove their identity, typically including a username and password. When a user logs in to a software system, they must provide the correct credential pair to verify their identity. A credential object can include a credential name and a credential value. For example, a credential object can be the username (credential name) and password (credential value) required to access a database system. Another example is an access key (AK), which includes a key pair consisting of a key name (used to identify the user) and a key value. For another example, a credential object may be the username (credential name) and password (credential value) required to log in to a cloud server. For example, the target cloud service may be a cloud service that provides resource object management services for cloud accounts. Establishing a binding relationship between the second cloud account and the target cloud service may involve: obtaining the total number of resource objects that the target cloud service can create from the target cloud service's resource specification information; if the number of valid resource objects already created by the target cloud service is less than the total number of resource objects that the target cloud service can create, establishing a binding relationship between the target cloud service and the second cloud account to share the target cloud service with the second cloud account within the scope of permissions granted to the second cloud account; the scope of permissions granted to the second cloud account is determined based on the resource objects created by the second cloud account using the target cloud service. Specifically, the instance specification information of the target cloud service may include resource specification information, which may specify the total number of resource objects that can be created using the target cloud service. For example, the resource specification information of a KMS instance may include the number of key objects and / or the number of credential objects that can be created. In practice, each time a target cloud service creates a resource object, the number of resource objects currently created by the target cloud service is updated in the increasing direction. For example, if a KMS instance allows 1000 key objects to be created, and the KMS instance has already created 500 key objects before the current creation, and the KMS instance creates 20 more key objects, then after these 20 key objects are created, the number of key objects created by the KMS instance is 520.In actual applications, if a created resource object is released, the number of currently created resource objects can be updated to decrease. For example, if a KMS instance has created 520 key objects and then deletes (releases) 10 key objects, the number of key objects created by the KMS instance is now 510. In this embodiment, the number of valid resource objects created by the target cloud service is dynamically maintained. Valid resource objects may be created but not yet released (deleted). If the number of valid resource objects created by the target cloud service is less than the total number of resource objects that the target cloud service can create, this indicates that the target cloud service can continue to create new resource objects (which can be understood as the target cloud service still has remaining resource usage quota). In this case, the target cloud service usage rights can be assigned to the second cloud account, thereby establishing a binding relationship between the target cloud service and the second cloud account. Of course, if the number of valid resource objects already created by the target cloud service equals the total number of resource objects that the target cloud service can create, this indicates that the target cloud service cannot create new resource objects (which can be understood as the target cloud service resource usage quota has been exhausted). In this case, the binding relationship between the target cloud service and the second cloud account will not be established. In this embodiment, the scope of permissions enjoyed by the second cloud account is determined based on the resource objects created by the second cloud account using the target cloud service. For example, the second cloud account can request the target cloud service to update, delete (or release) resource objects created by the second cloud account. For another example, the second cloud account can request the target cloud service to obtain resource objects created by the second cloud account and use these resource objects to perform various related operations such as data encryption, system login, and access authentication. In this embodiment, after establishing a binding relationship between the second cloud account and the target cloud service, the second cloud account can request the target cloud service to provide the target service to the second cloud account within the scope of the second cloud account's permissions. In actual applications, the scope of permissions enjoyed by the second cloud account varies depending on the target cloud service. For example, the target cloud service is a 32-core 96GB cloud server instance. Cloud account A1 owns a 32-core, 96GB cloud server instance. Cloud accounts B1 and B2 have usage rights to the 32-core, 96GB cloud server instance. Cloud account B1 can request that 8 cores and 32GB of computing resources from the 32-core, 96GB cloud server instance be allocated to cloud account B1. Cloud account B2 can request that 16 cores and 32GB of computing resources from the 32-core, 96GB cloud server instance be allocated to cloud account B2. For another example, the target cloud service is a 500GB cloud disk instance.Cloud account A1 owns a 500GB cloud disk instance, while cloud accounts B1 and B2 have usage rights to the 500GB cloud disk instance. Cloud account B1 can request that 100GB of storage resources be allocated to cloud account B1; cloud account B2 can request that 200GB of storage resources be allocated to cloud account B2. For another example, the target cloud service is a KMS instance with the following instance specifications: 1000 key objects allowed, 100 credential objects allowed. Cloud account A1 owns the KMS instance, while cloud accounts B1 and B2 have usage rights to the KMS instance. Cloud accounts B1 and B2 can request a KMS instance to create a certain number of key objects or credential objects. They can also request the KMS instance to update or delete the key objects or credential objects they requested. They can also request the KMS instance to retrieve the key objects or credential objects they created. KMS instances provide users with secure key escrow and cryptographic operations using keys, automating key management on their behalf. They can also use keys to perform cryptographic operations such as digital signing, encryption, and decryption. Furthermore, KMS instances offer encrypted credential storage, regular rotation, secure distribution, and centralized management. This mitigates the risks of plaintext credential configuration and supports rotation, effectively reducing the risk of credential leakage. Cloud accounts granted access to KMS instances can use various user-friendly services and features provided by KMS, including, but not limited to, creating, retrieving, deleting, and updating keys or credentials. In the embodiments of this disclosure, "key or credential update" includes user-triggered key or credential updates and may also include the process of rotating keys or credentials by a KMS instance to achieve updates. In some optional embodiments, an unbinding request for the target cloud service may be received, including a second cloud account; the binding relationship between the target cloud service and the second cloud account may be released. This removes the second cloud account's access rights to the target cloud service, enhancing the flexibility of resource sharing between multiple accounts on the target cloud service. Optionally, the unbinding request includes the identifiers of the second cloud account and the target cloud service, thereby accurately unbinding the binding relationship between the target cloud service and the second cloud account.In some optional embodiments, a first cloud account that owns the target cloud service can trigger a binding or unbinding request, allowing the resource owner to allocate resource usage permissions for the target cloud service. This reduces the resource sharing management burden of the target cloud service and facilitates resource sharing between multiple accounts. The multi-account cloud service sharing method provided in the disclosed embodiments can establish a binding relationship between the target cloud service and a second cloud account associated with the first cloud account for a target cloud service owned by the first cloud account, thereby granting the second cloud account usage rights. This allows the second cloud account to subsequently use the target cloud service within the scope of the second cloud account's permissions based on the binding relationship. This enables resource sharing of the target cloud service between multiple cloud accounts, eliminating the need for the target cloud service to be used solely by a single cloud account. This reduces the cost of using the target cloud service and increases its utilization or reuse rate. In some optional embodiments, the target cloud service provides resource object management services for cloud accounts. Resource object management services include, but are not limited to, creating, updating, retrieving, and releasing resource objects. Taking the target cloud service as a KMS instance as an example, resource object management services include, but are not limited to, creating key objects, updating key objects, obtaining key objects, deleting (i.e., releasing) key objects, creating credential objects, obtaining credential objects, and deleting (i.e., releasing) credential objects. Based on the above, in response to a service request from a second cloud account, and based on the binding relationship between the second cloud account and the target cloud service, controlling the target cloud service to provide the target service to the second cloud account within the scope of the second cloud account's permissions is implemented as follows: in response to a service request from the second cloud account, and based on the binding relationship between the second cloud account and the target cloud service, controlling the target cloud service to provide the second cloud account with at least one of the following services: creating, updating, obtaining, and releasing resource objects. In actual applications, any cloud account can initiate a service request to the target cloud service to request that the target cloud service provide the target service. Herein, the cloud account that initiates the service request to the target cloud service is referred to as the third cloud account. The third cloud account may be the first cloud account that owns the target cloud service, or the second cloud account that has the right to use the target cloud service, or any other cloud account other than the first cloud account and the second cloud account.Based on the above, in response to a service request from a second cloud account, based on the binding relationship between the second cloud account and the target cloud service, controlling the target cloud service to provide the second cloud account with at least one of the following services: creating, updating, acquiring, and releasing resource objects; receiving a service request from a third cloud account; determining whether the third cloud account is the first cloud account based on identification information of the third cloud account, where the identification information of the third cloud account may be an account name, password, or account ID; if the third cloud account is not the first cloud account, querying the established binding relationship between the second cloud account and the target cloud service; if a binding relationship between the third cloud account and the target cloud service is found, it indicates that the third cloud account belongs to the second cloud account that has established a binding relationship with the target cloud service and that the third cloud account has permission to use the target cloud service. Therefore, controlling the target cloud service to provide the third cloud account with at least one of the following services: creating, updating, acquiring, and releasing resource objects; specifically, after receiving the service request from the third cloud account, if it is determined that the third cloud account is not the first cloud account, querying the established binding relationship between the second cloud account and the target cloud service based on the third cloud account. If no binding relationship between the third cloud account and the target cloud service is found, it indicates that the third cloud account is not a second cloud account with permission to use the target cloud service. In this case, a message indicating that the third cloud account does not have permission to use the target cloud service can be returned to the third cloud account. If a binding relationship between the third cloud account and the target cloud service is found, it indicates that the third cloud account is a second cloud account with permission to use the target cloud service. In this case, the target cloud service is controlled to provide the third cloud account with at least one of the following services: create, update, obtain, and release resource objects. The following describes the target cloud service's provision of resource object creation, update, acquisition, and release services for a third-cloud account, specifically for different scenarios: Scenario 1: When the service request is a resource object creation request, the resource object creation request includes description information of the first resource object being requested. Controlling the target cloud service to provide resource object creation services for the third-cloud account is implemented as follows: When the service request is a resource object creation request, the resource object creation request includes description information of the first resource object being requested. Based on the number of resource objects currently creatable by the target cloud service and the description information of the first resource object, the first resource object is created. The first resource object has a creator tag, and the creator tag of the first resource object points to the third-cloud account. In actual applications, the description information of the first resource object may be information uniquely identifying the first resource object, including, but not limited to, the name or identifier of the first resource object. The description information of the first resource object may vary depending on the first resource object, but this is not limited to this. See the examples below.If a third cloud account is a second cloud account with usage rights for a target cloud service, when the third cloud account initiates a resource object creation request, the system determines whether the number of resource objects currently creatable by the target cloud service is less than the total number of resource objects that the target cloud service can create. If so, the system allows the creation of the first resource object. The created first resource object includes the first resource object's description information and object value. For example, if the first resource object is a key object, the first resource object's description information refers to the key name, and the first resource object's object value refers to the key value. For another example, if the first resource object is a credential object, the first resource object's description information refers to the credential name, and the first resource object's object value refers to the credential value. A creator tag is assigned to the created first resource object. The creator tag of the first resource object points to the third cloud account that created the first resource object; that is, the creator tag reflects the creator of the first resource object. It is worth noting that assigning a creator tag to the created first resource object can help limit the permissions of the second cloud account, so that the second cloud account can only update, retrieve, and delete resource objects created by the second cloud account. In actual applications, a resource object creation request initiated by a third cloud account instructs the creation of one or more first resource objects. For example, the number of first resource objects to be created is determined based on the number of first resource object descriptions in the resource object creation request. If the third cloud account requests the creation of multiple first resource objects, and if the number of resource objects currently creatable by the target cloud service is less than the total number of resource objects the target cloud service can create, the number of resource objects remaining creatable by the target cloud service is calculated by subtracting the number of resource objects currently creatable by the target cloud service from the total number of resource objects the target cloud service can create. Multiple first resource objects are created with the goal of ensuring that the number of first resource objects created does not exceed the total number of resource objects the target cloud service can create. Furthermore, when the third cloud account initiates a resource object creation request, it determines whether the number of resource objects currently creatable by the target cloud service is less than the total number of resource objects the target cloud service can create. If so, the target cloud service's resource usage quota has been exhausted, and no new resource objects can be created. In this case, a resource object creation failure message can be returned to the third cloud account, indicating that the third cloud account was unable to create the resource object. Optionally, to improve the utilization rate of the target cloud service, when creating the first resource objects, the number of resource objects currently creatable by the target cloud service is updated based on the number of first resource objects. It is understood that after the first resource objects are created, the number of resource objects currently creatable by the target cloud service is updated based on the number of first resource objects that have been created.Case 2: If the service request is a resource object update request and the resource object update request includes the description information of the second resource object, the target cloud service is controlled to provide the resource object update service to the third cloud account by: determining the second resource object and its creator tag based on the description information of the second resource object; and if the creator tag of the second resource object points to the third cloud account, updating the second resource object. Optionally, if the creator tag of the second resource object does not point to the third cloud account, a message indicating that the third cloud account does not have permission to update the resource object may be returned to the third cloud account. Case 3: If the service request is a resource object retrieval request and the resource object update request includes the description information of the third resource object, the target cloud service is controlled to provide the resource object retrieval service to the third cloud account by: determining the third resource object and its creator tag based on the description information of the third resource object; and if the creator tag of the third resource object points to the third cloud account, sending the third resource object to the application system corresponding to the third cloud account. Optionally, if the creator tag of the third resource object does not point to the third cloud account, a message indicating that the third cloud account does not have permission to retrieve the resource object may be returned to the third cloud account. Case 4: When the service request is a resource object acquisition request and the resource object update request includes the description information of the fourth resource object, the target cloud service is controlled to provide the resource object release service to the third cloud account by: determining the fourth resource object and its creator tag based on the description information of the fourth resource object; and deleting the fourth resource object if the creator tag of the fourth resource object points to the third cloud account. Optionally, if the creator tag of the fourth resource object does not point to the third cloud account, a message indicating that the third cloud account does not have permission to release the resource object may be returned to the third cloud account. Optionally, to improve the utilization rate of the target cloud service, when the fourth resource object is deleted, the number of resource objects currently creatable by the target cloud service may be updated based on the number of deleted fourth resource objects. In some optional embodiments, the second cloud account can only update, retrieve, and delete resource objects created by the second cloud account. However, since the first cloud account has a greater scope of permissions than the second cloud account, the first cloud account can update, retrieve, and delete resource objects created by the first cloud account and / or the second cloud account in the target cloud service. Based on this, after receiving the service request from the third cloud account, if the third cloud account is the first cloud account, the target cloud service is controlled to provide at least one service of creating, updating, acquiring and releasing resource objects for the third cloud account.In the case where the third cloud account is the first cloud account, at least one of updating, acquiring, and releasing the target resource object is performed using the target cloud service; the target resource object includes a resource object created by the first cloud account and / or the second cloud account. Figure 3 is a flowchart of a multi-account sharing method for a key management service instance provided in an embodiment of the present disclosure. Referring to Figure 3, the method may include the following steps:

[0005] 301. Receive a binding request for a key management service instance, where the binding request includes a second cloud account. The key management service instance is a cloud service owned by a first cloud account.

[0006] 302. When an association relationship is established between the second cloud account and the first cloud account, obtain the total number of resource objects that can be created by the key management service instance from resource specification information of the key management service instance.

[0007] 303. If the number of valid resource objects created by the key management service instance is less than the total number of resource objects that the key management service instance can create, establish a binding relationship between the key management service instance and the second cloud account to share the key management service instance with the second cloud account. 304. In response to a service request from the second cloud account, control the key management service instance to provide resource object management services to the second cloud account within the scope of permissions granted to the second cloud account based on the binding relationship between the second cloud account and the key management service instance. Optionally, the second cloud account and the first cloud account have a set association relationship, including at least one of the following: the second cloud account and the first cloud account are different cloud accounts registered by the same user on the cloud service platform; the second cloud account and the first cloud account are different cloud accounts registered on the cloud service platform by different users with a business relationship; the second cloud account and the first cloud account are different cloud accounts in the same resource directory, and the resource directory manages associated cloud accounts. Optionally, responding to a service request from a second cloud account and, based on the binding relationship between the second cloud account and the key management service instance, controlling the key management service instance to provide resource object management services for the second cloud account within the scope of permissions enjoyed by the second cloud account includes: responding to the service request from the second cloud account and, based on the binding relationship between the second cloud account and the key management service instance, controlling the key management service instance to provide the second cloud account with at least one of the services of creating, updating, acquiring, and releasing resource objects. Optionally, responding to the service request from the second cloud account and, based on the binding relationship between the second cloud account and the key management service instance, controlling the key management service instance to provide the second cloud account with at least one of the services of creating, updating, acquiring, and releasing resource objects includes: receiving a service request from a third cloud account; if the third cloud account is not the first cloud account, querying the established binding relationship between the second cloud account and the key management service instance; and if a binding relationship between the third cloud account and the key management service instance is found, controlling the key management service instance to provide the third cloud account with at least one of the services of creating, updating, acquiring, and releasing resource objects. Optionally, the method further includes: if the third cloud account is the first cloud account, controlling the key management service instance to provide at least one of the services of creating, updating, acquiring, and releasing resource objects for the third cloud account. Optionally, before controlling the key management service instance to provide at least one of the services of creating, updating, acquiring, and releasing resource objects for the third cloud account, the method further includes authenticating the third cloud account to ensure secure service access. For example, the method may involve invoking a rights management service to authenticate the third cloud account and determine whether the third cloud account has permission to access the key management service instance.Optionally, when the third cloud account is the first cloud account, controlling the key management service instance to provide the third cloud account with at least one of the services of updating, acquiring, and releasing resource objects, including: when the third cloud account is the first cloud account, using the key management service instance to perform at least one of the services of updating, acquiring, and releasing target resource objects; the target resource objects include resource objects created by the first cloud account and / or the second cloud account. Optionally, controlling the key management service instance to provide at least one of the services of creating, updating, acquiring, and releasing resource objects for the third cloud account includes: when the service request is a resource object creation request, the resource object creation request includes description information of a first resource object requested to be created; creating the first resource object based on the number of resource objects currently creatable by the key management service instance and the description information of the first resource object, the first resource object having a creator tag, and the creator tag of the first resource object pointing to the third cloud account; when the service request is a resource object update request, the resource object update request includes description information of a second resource object, and determining the second resource object and its creator tag based on the description information of the second resource object; when the creator tag of the second resource object points to the third cloud account, updating the second resource object; when the service request is a resource object acquisition request, the resource object update request includes description information of a third resource object, and determining the third resource object and its creator tag based on the description information of the third resource object; and when the creator tag of the third resource object points to the third cloud account, sending the third resource object to the application system corresponding to the third cloud account. Optionally, the method further includes: when creating the first resource object, updating the number of resource objects currently creatable by the key management service instance based on the number of the first resource objects. Optionally, the method further includes: receiving an unbinding request for the key management service instance, the unbinding request including the second cloud account; and releasing the binding relationship between the key management service instance and the second cloud account. The implementation of each step in the method provided by the embodiments of the present disclosure can refer to the relevant descriptions of the aforementioned embodiments and will not be repeated here. The multi-account sharing method for a key management service instance provided by the embodiments of the present disclosure can establish a binding relationship between the key management service instance and the second cloud account associated with the first cloud account for a key management service instance owned by the first cloud account, thereby granting the second cloud account the right to use the key management service instance. In this way, the second cloud account can subsequently use the key management service instance within the scope of the second cloud account's permissions based on the binding relationship.This enables resource sharing of key management service instances across multiple cloud accounts. Key management service instances are no longer restricted to a single cloud account, reducing the cost of using the key management service instance and improving its utilization rate. To better understand resource sharing of KMS instances across multiple accounts, the following scenario examples are described with reference to Figures 4 to 7. Scenario 1: In this scenario, the resource owner of a KMS instance grants the right to use the KMS instance to a resource user. As shown in Figure 4 (1), the resource owner corresponding to the first cloud account of the KMS instance performs a binding operation on the KMS instance frontend. As shown in Figure 4 (2), the KMS instance frontend responds to the binding operation by triggering a binding request and sends it to the KMS instance backend. The binding request includes the second cloud account. As shown in Figure 4 (3), the KMS instance backend establishes a binding relationship with the second cloud account, that is, a binding relationship between the second cloud account and the KMS instance. As shown in Figure 4 (4), the KMS instance queries the database to determine whether the KMS instance can be shared. Since the database stores created resource objects, querying the database for the number of created resource objects and the number of resource objects allowed to be created by the KMS instance can determine whether the KMS instance can be shared. As shown in Figure 4 (5), if the KMS instance can be shared, the currently established binding relationship for the second cloud account is saved in the database. As shown in Figure 4 (6), the KMS instance backend sends a binding success message to the KMS instance frontend. As shown in Figure 4 (7), the KMS instance frontend returns a resource sharing success result to the KMS instance resource owner. This completes the process of the KMS instance resource owner granting KMS instance usage rights to the resource user. As shown in Figure 4 (8), if the KMS instance cannot be shared, the KMS instance backend sends a binding failure message to the KMS instance frontend. As shown in Figure 4 (9), the KMS instance frontend returns a resource sharing failure result to the KMS instance resource owner. This indicates that the KMS instance resource owner has not granted KMS instance usage rights to the resource user. Scenario 2: In this scenario, the KMS instance resource owner revokes the resource user's KMS instance usage rights. As shown in Figure 5 (1), the resource owner of the first cloud account of the KMS instance performs an unbinding operation on the KMS instance frontend. As shown in Figure 5 (2), the KMS instance frontend triggers an unbinding request in response to the binding operation and sends it to the KMS instance backend. The unbinding request includes the second cloud account. As shown in Figure 5 (3), the KMS instance backend deletes the binding relationship of the second cloud account from the database, thereby releasing the binding relationship.As shown in step (4) of Figure 5 , the KMS instance backend sends a cancellation message to the KMS instance frontend. As shown in step (5) of Figure 5 , the KMS instance frontend returns a cancellation result to the KMS instance resource owner. This completes the process of the KMS instance resource owner revoking the resource user's use rights to the KMS instance. Scenario 2: In this scenario, the resource owner or resource user creates a credential object using the KMS instance. See Figure.

[0008] 6. The KMS instance frontend sends a credential object creation request from a third-cloud account to the KMS instance backend. After receiving the credential object creation request from the third-cloud account, the KMS instance backend determines whether the third-cloud account is the first-cloud account corresponding to the resource owner. If it is the first-cloud account, the KMS instance backend calls the permission management service to authenticate the third-cloud account and, after authentication, creates the credential object. If it is not the first-cloud account, the KMS instance backend determines whether the third-cloud account is the second-cloud account corresponding to the resource user. If it is the second-cloud account, the KMS instance backend calls the permission management service to authenticate the third-cloud account and, after authentication, creates the credential object. If it is not the second-cloud account, the creation process ends. Scenario 3: In this scenario, the resource owner or resource user uses the KMS instance to update the credential object. See Figure

[0009] 7. The KMS instance front-end sends a credential object update request from a third cloud account to the KMS instance back-end. After receiving the credential object update request from the third cloud account, the KMS instance back-end determines whether the third cloud account is the first cloud account corresponding to the resource owner. If it is the first cloud account, the KMS instance back-end calls the permission management service to authenticate the third cloud account, and updates the credential object after the authentication is passed. If it is not the first cloud account, the KMS instance back-end determines whether the third cloud account is the second cloud account corresponding to the resource user. If it is the second cloud account, the KMS instance back-end calls the permission management service to authenticate the third cloud account, and updates the credential object after the authentication is passed. If it is not the second cloud account, the update process ends. Scenario 4: In this scenario, the resource owner or resource user uses the KMS instance to obtain the credential object. See Figure

[0010] 8. The KMS instance front-end sends a credential object acquisition request from the third cloud account to the KMS instance back-end. After receiving the credential object acquisition request from the third cloud account, the KMS instance back-end determines whether the third cloud account is the first cloud account corresponding to the resource owner. If it is the first cloud account, the KMS instance back-end calls the permission management service to authenticate the third cloud account, and after the authentication is passed, the credential object is obtained and returned to the third cloud account. If it is not the first cloud account, the KMS instance back-end determines whether the third cloud account is the second cloud account corresponding to the resource user. If it is the second cloud account, the KMS instance back-end calls the permission management service to authenticate the third cloud account, and after the authentication is passed, the credential object is obtained and returned to the third cloud account. If it is not the second cloud account, the acquisition process ends. Figure 9 is a structural diagram of a multi-account sharing device for a cloud service provided in an embodiment of the present disclosure. See Figure

[0011] 9. The apparatus may include: a receiving module 91 for receiving a binding request for a target cloud service, the binding request including a second cloud account, the target cloud service being a cloud service owned by a first cloud account; a binding module 92 for establishing a binding relationship between the second cloud account and the target cloud service, if a set association relationship exists between the second cloud account and the first cloud account, so as to share the target cloud service with the second cloud account within the scope of permissions enjoyed by the second cloud account; and a control module 93 for responding to a service request from the second cloud account and, based on the binding relationship between the second cloud account and the target cloud service, controlling the target cloud service to provide the target service to the second cloud account within the scope of permissions enjoyed by the second cloud account. Optionally, the set association relationship between the second cloud account and the first cloud account includes at least one of the following: the second cloud account and the first cloud account are different cloud accounts registered by the same user on the cloud service platform; the second cloud account and the first cloud account are different cloud accounts registered by different users with a business relationship on the cloud service platform; or the second cloud account and the first cloud account are different cloud accounts in the same resource directory, where the resource directory manages associated cloud accounts. Optionally, establishing module 92 is specifically configured to: obtain, from the resource specification information of the target cloud service, the total number of resource objects that the target cloud service can create; and if the number of valid resource objects already created by the target cloud service is less than the total number of resource objects that the target cloud service can create, establish a binding relationship between the target cloud service and the second cloud account, thereby sharing the target cloud service with the second cloud account within the scope of permissions granted to the second cloud account; the scope of permissions granted to the second cloud account is determined based on the resource objects created by the second cloud account using the target cloud service. Optionally, controlling module 93 is specifically configured to: respond to a service request from the second cloud account and, based on the binding relationship between the second cloud account and the target cloud service, control the target cloud service to provide the second cloud account with at least one of the following services: creation, update, acquisition, and release of resource objects. Optionally, control module 93 is specifically configured to: receive a service request from a third cloud account; if the third cloud account is not the first cloud account, query the established binding relationship between the second cloud account and the target cloud service; and if a binding relationship between the third cloud account and the target cloud service is found, control the target cloud service to provide at least one of the following services: create, update, obtain, and release resource objects for the third cloud account. Optionally, control module 93 is further configured to: if the third cloud account is the first cloud account, control the target cloud service to provide at least one of the following services: create, update, obtain, and release resource objects for the third cloud account.Optionally, the control module 93 is specifically configured to: when the third cloud account is the first cloud account, use the target cloud service to update, acquire, and release the target resource object; the target resource object includes a resource object created by the first cloud account and / or the second cloud account. Optionally, the control module 93 is specifically configured to: if the service request is a resource object creation request, the resource object creation request includes description information of a first resource object to be created; based on the number of resource objects currently creatable by the target cloud service and the description information of the first resource object, create the first resource object, the first resource object having a creator tag, the creator tag of the first resource object pointing to a third cloud account; if the service request is a resource object update request, the resource object update request includes description information of a second resource object, determines the second resource object and its creator tag based on the description information of the second resource object; if the creator tag of the second resource object points to the third cloud account, update the second resource object; if the service request is a resource object acquisition request, the resource object update request includes description information of a third resource object, determines the third resource object and its creator tag based on the description information of the third resource object; if the creator tag of the third resource object points to the third cloud account, send the third resource object to the application system corresponding to the third cloud account. Optionally, the control module 93 is further configured to: when creating the first resource object, update the number of resource objects currently creatable by the target cloud service based on the number of the first resource objects. Optionally, the apparatus further includes an unbinding module configured to receive an unbinding request for a target cloud service, the unbinding request including the second cloud account, and to release the binding relationship between the target cloud service and the second cloud account. Optionally, the target cloud service is a key management service instance, and the resource objects include key objects and / or credential objects. The apparatus shown in FIG9 can execute the method shown in the embodiment shown in FIG1 or FIG3 , and its implementation principles and technical effects are not further described. The specific manner in which the various modules and units of the apparatus shown in FIG9 in the above embodiment perform operations has been described in detail in the embodiment related to the method and will not be elaborated upon here. It should be noted that the execution entity of each step of the method provided in the above embodiment can be the same device, or the method can be executed by different devices. For example, the execution entity of steps 101 to 103 can be device A; for another example, the execution entity of steps 101 and 102 can be device A, and the execution entity of step 103 can be device B; and so on.In addition, some processes described in the above embodiments and accompanying figures include multiple operations that appear in a specific order. However, it should be understood that these operations may be executed in a different order than the order in which they appear herein or in parallel. Operation numbers such as 101 and 102 are merely used to distinguish between different operations and do not represent any specific execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. It should be noted that terms such as "first" and "second" are used herein to distinguish between different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types. It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display) involved in this disclosure are all authorized by the user or fully authorized by all parties. The collection, use, and processing of these data must comply with relevant laws, regulations, and standards in the relevant regions, and corresponding operation portals are provided for users to choose to authorize or reject. Figure 10 is a schematic diagram of the structure of a computer device provided in an embodiment of the present disclosure. As shown in Figure 10 , the computer device includes: a memory 11 and a processor 12. The memory 11 is used to store computer programs 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 operating on the computing platform, contact data, phone book data, messages, images, videos, etc. The memory 11 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 storage, flash memory, magnetic disk, or optical disk.The processor 12 is coupled to the memory 11 and is configured to execute the computer program stored in the memory 11 to perform the steps of the multi-account sharing method for a cloud service or the multi-account sharing method for a key management service instance. Optionally, as shown in FIG10 , the computer device also includes other components, such as a communication component 13, a display 14, a power supply component 15, and an audio component 16. FIG10 schematically illustrates only some of the components and does not imply that the computer device only includes the components shown in FIG10 . Furthermore, the components within the dashed box in FIG10 are optional, not mandatory, components, depending on the product form factor of the computer device. The computer device of this embodiment can be implemented as a terminal device such as a desktop computer, a laptop computer, a smartphone, or an IoT (Internet of Things) device, or as a server-side device such as a conventional server, a cloud server, or a server array. If the computer device of this embodiment is implemented as a terminal device such as a desktop computer, laptop computer, or smartphone, it may include the components within the dashed box in Figure 10. If the computer device of this embodiment is implemented as a server-side device such as a conventional server, cloud server, or server array, it may not include the components within the dashed box in Figure 10. The detailed implementation process of the processor executing each action can be found in the relevant descriptions of the aforementioned method embodiments or device embodiments and will not be repeated here. Accordingly, the present disclosure also provides a computer-readable storage medium storing a computer program. When executed, the computer program can implement the steps that can be performed by the computer device in the aforementioned method embodiments. Accordingly, the present disclosure also provides a computer program product, including a computer program / instructions. When executed by a processor, the computer program / instructions causes the processor to implement the steps that can be performed by the computer device in the aforementioned method embodiments. The aforementioned communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device where the communication component resides can access a wireless network based on a communication standard, such as WiFi (Wireless Fidelity), 2G (2nd Generation), 3G (3rd Generation), 4G (4th Generation) / LTE (Long Term Evolution), 5G (5th Generation), or other mobile communication networks, or a combination thereof. In an exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.In one exemplary embodiment, the communication component also 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), infrared data association (IrDA), ultra-wideband (UWB), Bluetooth (BT), and other technologies. The aforementioned display includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, it can be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, slides, and gestures on the touch panel. The touch sensors can not only detect the boundaries of a touch or slide action, but also the duration and pressure associated with the touch or slide action. The aforementioned power supply component provides power to the various components of the device in which 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 to the device in which the power supply component resides. The aforementioned audio component may be configured to output and / or input audio signals. For example, the audio component may include a microphone (MIC) configured to receive external audio signals when the device in which the audio component resides is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals may be further stored in a memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals. Those skilled in the art will appreciate that embodiments of the present disclosure may be provided as methods, systems, or computer program products. Therefore, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present disclosure may take the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The present disclosure is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure.It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, such that the instructions, when executed by the processor of the computer or other programmable data processing device, produce a device for implementing the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams. These computer program instructions can also be stored in a computer-readable memory capable of directing the computer or other programmable data processing device to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams. These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing the computer or other programmable device to execute a series of operational steps to produce a computer-implemented process. The instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more flow charts and / or one or more blocks in the block diagrams. In a typical configuration, a computing device includes one or more processors (Central Processing Units, CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-volatile memory in the form of computer-readable media, random access memory (RAM), and / or non-volatile memory, such as read-only memory (ROM) or flash memory. Memory is an example of computer-readable media. Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can implement information storage using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data.Examples of computer storage media include, but are not limited to, Phase Change RAM (PRAM), Static Random-Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves. It should also be noted that the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, product, or apparatus comprising a list of elements may include not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, product, or apparatus. Without further limitation, the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, product, or apparatus comprising the elements. The foregoing are merely examples of the present disclosure and are not intended to limit the present disclosure. Those skilled in the art will readily appreciate that various modifications and variations of the present disclosure are possible. Any modifications, equivalent substitutions, improvements, and the like made within the spirit and principles of the present disclosure are intended to be encompassed by the claims of the present disclosure.

Claims

Claims 1. A multi-account sharing method for cloud services, wherein: include: receiving a binding request for a target cloud service, the binding request including a second cloud account, the target cloud service being a cloud service owned by the first cloud account; In a case where the second cloud account has a set association relationship with the first cloud account, a binding relationship is established between the second cloud account and the target cloud service to share the target cloud service with the second cloud account within the scope of permissions enjoyed by the second cloud account; and in response to a service request from the second cloud account, based on the binding relationship between the second cloud account and the target cloud service, the target cloud service is controlled to provide the target service to the second cloud account within the scope of permissions enjoyed by the second cloud account.

2. The method according to claim 1, wherein: The second cloud account and the first cloud account have a set association relationship, including at least one of the following: the second cloud account and the first cloud account are different cloud accounts registered by the same user on the cloud service platform; The second cloud account and the first cloud account are different cloud accounts registered on the cloud service platform by different users having a business relationship; The second cloud account and the first cloud account belong to different cloud accounts in the same resource directory, and the resource directory manages cloud accounts with associated relationships.

3. The method according to claim 1 or 2, wherein: The target cloud service is a cloud service that provides resource object management services for the cloud account, and establishing a binding relationship between the second cloud account and the target cloud service includes: obtaining, from resource specification information of the target cloud service, the total number of resource objects that the target cloud service can create; if the number of valid resource objects already created by the target cloud service is less than the total number of resource objects that the target cloud service can create, establishing a binding relationship between the target cloud service and the second cloud account, so as to share the target cloud service with the second cloud account within a scope of permissions enjoyed by the second cloud account; wherein the scope of permissions enjoyed by the second cloud account is determined based on the resource objects created by the second cloud account using the target cloud service.

4. The method according to claim 3, wherein: Responding to the service request from the second cloud account, and controlling the target cloud service to provide the target service to the second cloud account within the scope of permissions enjoyed by the second cloud account based on the binding relationship between the second cloud account and the target cloud service, includes: responding to the service request from the second cloud account, and controlling the target cloud service to provide the second cloud account with at least one service of creating, updating, obtaining, and releasing a resource object based on the binding relationship between the second cloud account and the target cloud service.

5. The method according to claim 4, wherein: Respond to the service request from the second cloud account according to The binding relationship between the second cloud account and the target cloud service, and controlling the target cloud service to provide at least one of creation, update, acquisition, and release of resource objects for the second cloud account, includes: receiving a service request from a third cloud account; if the third cloud account is not the first cloud account, querying for an established binding relationship between the second cloud account and the target cloud service; and if a binding relationship between the third cloud account and the target cloud service is found, controlling the target cloud service to provide at least one of creation, update, acquisition, and release of resource objects for the third cloud account.

6. The method according to claim 5, wherein: Also includes: In a case where the third cloud account is the first cloud account, the target cloud service is controlled to provide at least one service of creating, updating, acquiring, and releasing a resource object for the third cloud account.

7. The method according to claim 6, wherein: When the third cloud account is the first cloud account, controlling the target cloud service to provide the third cloud account with at least one of updating, acquiring, and releasing resource objects includes: when the third cloud account is the first cloud account, using the target cloud service to perform at least one of updating, acquiring, and releasing target resource objects; the target resource objects include resource objects created by the first cloud account and / or the second cloud account.

8. The method according to claim 5, wherein: Controlling the target cloud service to provide at least one of the following services for the third cloud account: creating, updating, acquiring, and releasing a resource object, the service request including: if the service request is a resource object creation request, the resource object creation request including description information of a first resource object requested for creation; creating the first resource object based on the number of resource objects currently creatable by the target cloud service and the description information of the first resource object, the first resource object having a creator tag, the creator tag of the first resource object pointing to the third cloud account; if the service request is a resource object update request, the resource object update request including description information of a second resource object, determining the second resource object and its creator tag based on the description information of the second resource object; updating the second resource object if the creator tag of the second resource object points to the third cloud account; if the service request is a resource object acquisition request, the resource object update request including description information of a third resource object, determining the third resource object and its creator tag based on the description information of the third resource object; and sending the third resource object to an application system corresponding to the third cloud account if the creator tag of the third resource object points to the third cloud account.

9. The method according to any one of claims 1 to 8, wherein: Also includes: receiving an unbinding request for the target cloud service, wherein the unbinding request includes the second cloud account; Unbind the target cloud service from the second cloud account.

10. The method according to any one of claims 1 to 8, wherein: The target cloud service is a key management service implementation For example, a resource object includes a key object and / or a credential object.

11. A method for sharing multiple accounts of a key management service instance, wherein: include: receiving a binding request for a key management service instance, the binding request including a second cloud account, the key management service instance being a cloud service owned by the first cloud account; In a case where an association relationship is set between the second cloud account and the first cloud account, obtaining, from resource specification information of the key management service instance, a total number of resource objects that the key management service instance can create; if the number of valid resource objects already created by the key management service instance is less than the total number of resource objects that the key management service instance can create, establishing a binding relationship between the key management service instance and the second cloud account to share the key management service instance with the second cloud account; and in response to a service request from the second cloud account, controlling the key management service instance to provide resource object management services for the second cloud account within a scope of authority enjoyed by the second cloud account based on the binding relationship between the second cloud account and the key management service instance.

12. A computer device, wherein: include: memory and processor; The memory is used to store computer programs; The processor is coupled to the memory, and is configured to execute the computer program to perform the steps of the method according to any one of claims 1 to 1.

13. A computer-readable storage medium storing a computer program, wherein: When the computer program is executed by a processor, the processor is enabled to implement the steps of the method according to any one of claims 1 to 11.

14. A computer program product, wherein: The computer program / instructions include a computer program / instructions, which, when executed by a processor, enables the processor to implement the steps of the method according to any one of claims 1 to 11.

Images