Access control method, device, system, equipment, storage medium and program product

Abstract

The invention provides a multi-tenant access control method, device, system and equipment, a storage medium and a program product, the multi-tenant access control method is applied to a front agent module of a server, and comprises the following steps: sending a resource access request by a client of any tenant, and determining identity information in a service account mounted by the resource access request; determining an initiating tenant initiating the resource access request based on the identity information in the service account; according to the permission configuration information of the initiating tenant and the identity information in the service account, determining a target tenant whose resource access request has permission to access; the permission configuration information of the initiating tenant is used for declaring target tenants allowed to be accessed by the initiating tenant and service accounts for accessing the target tenants. According to the method and the device, effective permission isolation can be carried out among the tenants under the condition of improving the utilization rate of cluster resources.

Description

Technical Field

[0001] This application belongs to the field of Internet technology, specifically relating to an access control method, device, system, equipment, storage medium, and program product. Background Technology

[0002] In a private cloud model, a cloud service provider offers a dedicated, isolated cloud computing environment to a single tenant or a group of related tenants. A tenant refers to an independent cloud product that enjoys resources and infrastructure within that private cloud environment. Specifically, this can be an independent cloud product deployed on a PaaS platform, such as Kafka (a distributed message queue) or EDA (Enterprise Distributed Application Service). A private cloud can have one or more tenants, each of whom can autonomously manage and operate their own service applications within their allocated resource scope, enjoying a degree of resource exclusivity and a high level of management authority.

[0003] As the number of tenants in cloud services continues to increase, problems such as non-standard resource sharing and excessive permission requests among different tenants have gradually emerged. Therefore, ensuring effective permission isolation between tenants has become a problem that needs to be solved.

[0004] It should be noted that the above statements are only used to provide background information related to this application and do not necessarily constitute prior art. Summary of the Invention

[0005] This application proposes an access control method, apparatus, system, device, storage medium, and program product that can effectively isolate permissions between tenants while improving the utilization of cluster resources, thereby solving problems such as non-standard resource sharing and excessive permission requests between different tenants in the prior art.

[0006] The first aspect of this application proposes a multi-tenant access control method, including:

[0007] Receive a resource access request sent by any tenant's client and determine the identity information in the service account to which the resource access request is attached;

[0008] The tenant that initiated the resource access request is determined based on the identity information in the service account.

[0009] Based on the permission configuration information of the initiating tenant and the identity information in the service account, the destination tenant that the resource access request has permission to access is determined. The permission configuration information of the initiating tenant is used to declare the destination tenant that the initiating tenant is allowed to access and the service account that accesses each destination tenant.

[0010] In some embodiments of this application, determining the initiating tenant who initiated the resource access request based on the service account includes:

[0011] The tenant affiliation information of the service account is queried from the environment configuration information; the environment configuration information includes the tenant affiliation information of each service account; the tenant affiliation information of the service account is used to identify the tenant to which the service account belongs;

[0012] Based on the tenant affiliation information of the service account, the initiating tenant that initiated the resource access request is determined.

[0013] In some embodiments of this application, determining the destination tenant with permission to access the resource based on the permission configuration information of the initiating tenant and the service account includes:

[0014] Based on the permission configuration information, the first destination tenant that the initiating tenant has permission to access is determined;

[0015] Based on the service account, a second destination tenant with the permission to access the resource access request is selected from the first destination tenant.

[0016] In some embodiments of this application, after determining the destination tenant with permission to access the resource access request based on the permission configuration information of the initiating tenant and the service account, the method further includes:

[0017] Determine the target resource object requested by the resource access request;

[0018] When the resource access request is a list request, destination tenant identifier information is added to the request parameters of the resource access request. The list request indicates that the request requests access to multiple destination tenants, and the tags of the destination tenants are used to identify the destination tenants that the resource access request has permission to access; or,

[0019] In the case that the resource access request is a single request, resource access requests from tenants to which the target resource object belongs that are not the destination tenant are intercepted. The single request indicates that the request is to access a destination tenant.

[0020] In some embodiments of this application, adding destination tenant identification information to the request parameters of the resource access request includes:

[0021] Determine the query parameters of the resource access request;

[0022] Add the tenant name of each destination tenant to the selector label of the query parameters.

[0023] In some embodiments of this application, the method further includes:

[0024] When the resource access request includes a list request, the access control for the resource access request is performed based on the destination tenant who has the permission to access the resource.

[0025] When the resource access request includes a single request, the access control for the resource access request is performed based on the destination tenant to which the target resource object belongs.

[0026] In some embodiments of this application, the method further includes:

[0027] During the access control phase of the permission management, if the request type of the resource access request is a write request, tenant ownership information is added to the target resource object.

[0028] In some embodiments of this application, before determining the initiating tenant who initiated the resource access request based on the service account, the method further includes:

[0029] During the resource object publishing process corresponding to the service account, the tenant affiliation information of each service account is parsed.

[0030] The tenant affiliation information of the service account is added to the metadata information of the service account; the metadata information of the service account is stored in the environment configuration information.

[0031] A second aspect of this application provides a multi-tenant access control device, the device comprising:

[0032] The service account determination module is used to receive resource access requests sent by any tenant's client and determine the identity information in the service account attached to the resource access request;

[0033] The initiating tenant determination module is used to determine the initiating tenant that initiates the resource access request based on the identity information in the service account.

[0034] The destination tenant determination module is used to determine the destination tenant that the resource access request has permission to access based on the permission configuration information of the initiating tenant and the identity information in the service account; the permission configuration information of the initiating tenant is used to declare the destination tenant that the initiating tenant is allowed to access and the service account that accesses each destination tenant.

[0035] An embodiment of the third aspect of this application provides a multi-tenant access control system applied to a cloud platform in a multi-tenant scenario. The multi-tenant access control system includes an interface service module and a front-end agent module.

[0036] The front-end proxy module is used to intercept resource access requests sent by any tenant's client to the interface service module, and determine the identity information in the service account attached to the resource access request; determine the initiating tenant that initiated the resource access request based on the identity information in the service account; and determine the destination tenant that the resource access request has permission to access based on the permission configuration information of the initiating tenant and the identity information in the service account. The permission configuration information of the initiating tenant is used to declare the destination tenant that the initiating tenant is allowed to access and the service account that accesses each destination tenant.

[0037] The interface service module performs an access control process on the resource access request based on the destination tenant that has permission to access the resource.

[0038] In some embodiments of this application, when the resource access request is a write request during the access control phase of the permission management process, the interface service module adds tenant ownership information to the target resource object corresponding to the resource access request.

[0039] An embodiment of the fourth aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the method as described in the first aspect.

[0040] An embodiment of the fifth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, characterized in that the program is executed by a processor to implement the method as described in the first aspect.

[0041] An embodiment of the sixth aspect of this application provides a computer program product including a computer program that is executed by a processor to implement the method described in the first aspect.

[0042] The technical solutions provided in this application embodiment have at least the following technical effects or advantages:

[0043] In this embodiment, each tenant is configured with permissions to access other tenants and permissions to allow other tenants to access resources. When a user of a tenant initiates a resource access request to the server, the initiating tenant of the resource access request can be determined first based on the service account attached to the resource access request. Then, based on the permission configuration information of the initiating tenant and the identity information of the service account, the destination tenant for the resource access request initiated by the client of the initiating tenant and attached to the service account can be determined. This achieves a coarse screening function for the destination tenant of the resource access request, limiting the destination tenant of the resource access request to the permission configuration information of the initiating tenant. Thus, tenant-level permission verification is performed before the server performs permission control on the resource access request, thereby realizing a tenant-level resource isolation function. Moreover, no modification to tenant information is required during the resource isolation process, making it more universally applicable. At the same time, this multi-tenant access control method can realize the control and management of multiple tenants based on the same control center. That is, multiple tenants can share basic resource facilities without creating a corresponding control plane or Kubernetes cluster for each tenant, improving the utilization of cluster resources and reducing resource waste. It does not affect the architecture and mode of other components in the Kubernetes cluster, making system operation and maintenance easier.

[0044] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0045] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings.

[0046] In the attached diagram:

[0047] Figure 1 This demonstrates a private cloud multi-tenant application scenario;

[0048] Figure 2 A schematic diagram of the framework structure of an access control system provided in some embodiments of this application is shown;

[0049] Figure 3 A flowchart illustrating a multi-tenant access control method provided in some embodiments of this application is shown;

[0050] Figure 4 The following is a detailed flowchart of step S2 in some embodiments of this application;

[0051] Figure 5A detailed flowchart of step S3 in some embodiments of this application is shown;

[0052] Figure 6 A flowchart illustrating a multi-tenant access control method provided in some embodiments of this application is shown;

[0053] Figure 7 A flowchart illustrating a multi-tenant access control method provided in other embodiments of this application is shown;

[0054] Figure 8 This paper illustrates a detailed flowchart of a multi-tenant access control method provided in an embodiment of this application.

[0055] Figure 9 This application provides a schematic diagram of the structure of a multi-tenant access control device according to some other embodiments.

[0056] Figure 10 A schematic diagram of an electronic device provided according to an embodiment of this application is shown;

[0057] Figure 11 A schematic diagram of a storage medium provided in one embodiment of this application is shown. Detailed Implementation

[0058] Exemplary embodiments of this application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of this application and to fully convey the scope of this application to those skilled in the art.

[0059] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. All data involved in this application (including but not limited to data used for model training, stored data, and displayed data) are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of such data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding access points are provided for users to choose whether to authorize or refuse authorization.

[0060] First, some of the nouns or terms appearing in the embodiments of this application can be interpreted as follows:

[0061] Multi-tenant private cloud: also known as private public cloud, multi-tenancy is an architectural pattern that allows different users or organizations to share the same infrastructure and resources while remaining isolated from each other by creating multiple independent tenant environments within a single system, thus protecting data security and resource allocation. A multi-tenant architecture can support multiple tenants within a single instance and provide independent resource allocation, isolated environments, and access control.

[0062] Kubernetes (K8s) is an open-source container orchestration platform designed to simplify application deployment, scaling, and management. It provides automated container orchestration, service discovery and load balancing, self-healing, and horizontal scaling, making it simpler and more reliable to run and manage applications in a containerized environment. The aforementioned cloud computing service models can be created based on Kubernetes clusters, but are not limited to those described above.

[0063] A PaaS (Platform as a Service) platform in a private cloud: In a private cloud environment, a PaaS platform provides users with a suite of development tools, runtime environments, database management systems, message queues, authentication, and other services, aiming to provide developers with application development, deployment, and management capabilities. Specifically, a PaaS platform can be built on Kubernetes, enabling unified application management, heterogeneous resource management, and intelligent operation and maintenance capabilities. Tenants can access cloud services through this PaaS platform.

[0064] RBAC: Role-Based Access Control (RBAC) is an access control mechanism that uses role-based permission definitions and authorization to manage and control the access and operation permissions of users, groups, and service accounts to system resources. By using RBAC, different users or groups can be assigned to different roles, and specific permissions can be assigned to each role. This allows administrators to control different users' access to and operation of cluster resources as needed.

[0065] In Kubernetes, native objects defined for RBAC include Role, ClusterRole, RoleBinding, and ServiceAccount. These native objects allow administrators to control user and service account permissions to Kubernetes resources with fine granularity as needed, thereby improving cluster security and manageability.

[0066] Among them, Role: Defines a set of permissions for specific resources and can be bound to a user or service account within a namespace. ClusterRole: Similar to Role, but can grant permissions across the entire cluster. RoleBinding: Binds a Role to a user or service account within a namespace, specifying who can access certain resources. ClusterRoleBinding: Binds a ClusterRole to a user or service account across the cluster, specifying who can access certain resources throughout the cluster. ServiceAccount: A resource object in Kubernetes used to provide authentication and authorization for Pods (the smallest unit of deployment and management in a Kubernetes cluster, a collection of one or more containers, or an abstract collection of one or more services or processes). It enables Pods to interact with the Kubernetes API and perform corresponding operations, and is an important component of RBAC.

[0067] Kubernetes' native namespace isolation and RBAC authorization mechanisms can achieve a certain level of resource isolation. Specifically, different resources can be grouped into different namespaces to achieve resource isolation between different products or organizations. However, the use of namespaces and RBAC has some limitations in multi-tenant isolation scenarios. On the one hand, namespaces and RBAC provide coarse-grained resource isolation and access control, which cannot meet some finer-grained isolation and control needs. For example, if you want to configure list permissions, these permissions will apply to all resources in the entire environment, not just some resources in the environment. Here, the resources of the entire environment can be understood as the complete application running in the Kubernetes cluster and its related resources, including but not limited to containers, storage, network, and logging. On the other hand, there is already a phenomenon in private cloud services where multiple tenants share the same namespace and the same RBAC. Multiple tenants using the same namespace and RBAC cannot achieve good isolation, which can lead to excessive tenant permissions, and effectively managing this phenomenon requires significant costs.

[0068] With the continuous development of cloud service technology, it has achieved such Figure 1The illustrated scenario depicts a multi-tenant application in a private cloud. In this scenario, multiple tenants (tenant 1-tenant n in the diagram) connect to the same private cloud service platform, such as a PaaS platform, sharing the same network infrastructure resources. Resource isolation between tenants is achieved through access control. However, as more and more tenants connect to the PaaS platform, problems such as non-standard resource sharing and excessive permission requests among tenants are becoming increasingly serious. Related technologies include vcluster (virtual cluster), clusterapi (cluster API), and kubezoo. These three components can be used to achieve tenant isolation, but each has its own shortcomings, as detailed below:

[0069] vCluster is a virtualized cluster management component that creates an independent control panel for each tenant, including components such as the controller, apiserver (interface service module), and etcd (storage system). Each tenant has its own dedicated control plane. However, this method of tenant isolation, which assigns independent management components to each tenant, suffers from low resource utilization, leading to significant resource waste and increased operational costs for multiple components.

[0070] The clusterapi is used to manage the lifecycle of Kubernetes clusters, allowing each tenant to create an independent Kubernetes cluster, thus achieving more thorough tenant isolation. However, like vcluster, this solution suffers from low resource utilization and is incompatible with current private cloud deployment architectures.

[0071] The Kubezooi-based tenant isolation solution is a lightweight multi-tenant management solution. It creates an independent management API server and modifies request information and resource names based on the requester's identity, giving each tenant's resources the same prefix, thus achieving tenant-level access control. However, this solution is relatively complex to implement. When resources reference other resources, the complexity of data tampering increases significantly. For example, when a custom object references a native object, the mapping relationship for that custom object needs to be manually maintained. Furthermore, this solution lacks inter-tenant interaction capabilities; it cannot support resource access between tenants.

[0072] To address the aforementioned issues, this application provides a multi-tenant access control method, apparatus, system, electronic device, storage medium, and program product. This access control method can be applied to a server. In this method, each tenant is configured with permissions to access other tenants and permissions to allow other tenants to access resources. When a user of a tenant initiates a resource access request to the server, the initiating tenant of the resource access request can be determined first based on the service account attached to the resource access request. Then, based on the initiating tenant's permission configuration information and the service account's identity information, the destination tenant that the resource access request has permission to access is determined. Thus, before the server performs permission control on the resource access request, tenant-level permission verification is performed, achieving a coarse screening function for the destination tenant of the resource access request. This limits the destination tenant of the resource access request to the initiating tenant's permission configuration information, thereby realizing a tenant-level resource isolation function.

[0073] This multi-tenant access control method can be applied to, for example... Figure 2 The access control system shown can include an interface service module and a front-end proxy module deployed before the interface service module. This module intercepts resource access requests sent by tenants to the interface service module via clients, determines the initiating tenant based on the service account attached to the resource access request, and then determines the destination tenant with the necessary permissions based on the initiating tenant's permission configuration information and the service account information. This allows for tenant-level permission verification of resource access requests before they reach the interface service module, achieving tenant-based resource isolation. The interface service module manages access permissions for resource access requests, including but not limited to executing authentication, authorization, and admission control processes. The specific processes of these processes can refer to the standard Kubernetes RBAC process and will not be elaborated here. The interface service module can be, but is not limited to, the aforementioned apiserver, as long as it can manage access permissions for resource access requests.

[0074] It is understood that this system can be applied to, but is not limited to, private cloud platform PaaS, as well as other private cloud platforms and public cloud platforms that require multi-tenant isolation. It can also be applied to physical machines that support and implement this cloud service; this embodiment does not specifically limit this application.

[0075] The aforementioned electronic device can be any device capable of executing the multi-tenant access control method, specifically a physical computer device or a cloud server; this embodiment does not impose specific limitations on this. The aforementioned apparatus can be a module on the electronic device specifically used to execute the multi-tenant access control method; this embodiment does not impose specific limitations on its specific structure. The aforementioned computer-readable storage medium stores a computer program capable of implementing the multi-tenant access control method; it can be any computer-readable storage medium capable of storing a computer program; this embodiment does not impose specific limitations on its specific structure. The aforementioned computer program product can be any product including the aforementioned computer program; this embodiment does not impose specific limitations on its specific implementation form and structure.

[0076] The technical solutions provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0077] Please see Figure 3 This is a flowchart illustrating the multi-tenant access control method provided in an embodiment of this application, as shown below. Figure 3 As shown, this multi-tenant access control method, applied to the server side, may include the following steps:

[0078] Step S1: Receive a resource access request sent by any tenant's client and determine the identity information in the service account to which the resource access request is attached;

[0079] Step S2: Determine the initiating tenant that initiated the resource access request based on the identity information in the service account;

[0080] Step S3: Based on the permission configuration information of the initiating tenant and the identity information in the service account, determine the target tenant that the resource access request has permission to access.

[0081] In this context, the client is the application or device through which the user interacts with the server. It is responsible for sending requests to the server and displaying the information returned by the server. Specifically, the client can be a browser, mobile application, desktop application, etc. In this embodiment, the client can be logged into by any user account of the tenant. Through this client, resource access requests can be initiated to the interface service module of the PaaS platform, realizing the communication connection between the tenant and the cloud service. This resource access request is used to request access to a specific resource or perform a specific operation. Specifically, it can be a write request, such as a request to create a resource, a request to modify resource information, or a request to delete information; or it can be a read request, such as a list watch request. The resource object in the resource access request can be a list or a single resource. When the resource object is a list, there can be multiple destination tenants. When the resource object is a single resource, there is usually one destination tenant or a few specific ones.

[0082] This section receives resource access requests sent by clients, and can either actively acquire resource access requests or intercept resource access requests.

[0083] Both the initiating tenant and the destination tenant that initiates the resource access request can be any tenant accessing the PaaS platform service; this embodiment does not impose specific limitations on this. The service account is the native RBAC object ServiceAccount mentioned above, and the identity information in the service account may include, but is not limited to, the service account name.

[0084] In practical applications, cloud service baselines can be used to define a set of minimum standards or basic requirements for a cloud service environment to ensure the security and availability of the cloud service operating environment. These baselines can include requirements for hardware, software, network configuration, security policies, etc., aiming to ensure that the cloud service environment can meet the security compliance requirements of an organization or industry. When accessing cloud services, each tenant can configure the aforementioned RBAC native objects and the permissions of each tenant by configuring the tenant's baseline in the cloud service.

[0085] The baseline declaration definition only takes effect after being submitted to the Kubernetes cluster runtime environment by the publishing module. The publishing module can submit the native RBAC objects defined by tenants in the cloud service baseline to the Kubernetes cluster; this process is called the baseline publishing process. In this embodiment, during the baseline publishing process, the publishing module can parse the native RBAC and generate RBAC instance objects to implement the permission control process for resource access requests. The publishing module can also parse the Enhanced Role-Based Access Control (ERBAC) mechanism based on the permission configuration information of each tenant, generate ERBAC instance objects, and manage access control initiated by tenants based on these ERBAC instance objects to achieve multi-tenant resource isolation.

[0086] This embodiment can set the permissions that each tenant publicly discloses and the permissions that other tenants are allowed to access before determining the target tenant for the resource access request, thus forming the permission configuration information of each tenant; based on the permission configuration information of each tenant, a corresponding access control object instance is created.

[0087] The aforementioned permission configuration information for the initiating tenant can declare the target tenants that the initiating tenant is allowed to access and the service accounts that can access each target tenant. This includes which tenants the initiating tenant can access, and the scope of the access permission. The scope can include declarations of two types of accounts: service accounts and users. That is, the access permission can only be granted by the declared user and service account; otherwise, the front-end proxy module can intercept the request. The permission configuration information for the initiating tenant can also declare the permissions that the initiating tenant publicly discloses, i.e., which tenants can access which resources of the initiating tenant.

[0088] Specifically, but not limited to, the following baseline declaration model may be adopted:

[0089] AccessPolicy: # Defines the access policy

[0090] From: # Define which tenants can access which resources of this tenant.

[0091] -tenants:["tenant name"] # Defines which tenants have permission to access this tenant.

[0092] Resources: # Defines which resources within this tenant can be exposed to the outside world.

[0093] -groups:["resource groups"]#Resource groups that can be made public.

[0094] versions:["resource versions"]#Resource versions that can be made public.

[0095] kinds:["resource type"]#Resource types that can be made public.

[0096] to: # Define which service accounts of "this tenant" can access resources within which tenants.

[0097] -tenants:["tenant name 1","tenant name 2"]#The target tenants that this tenant can access.

[0098] Accounts: # Defines the service accounts for which this tenant is granted permissions.

[0099] -serviceAccount: #Service account configuration

[0100] namespace: "ServiceAccount namespace" # The namespace where the service account resides

[0101] name: "ServiceAccount Name" # The name of the service account

[0102] -user:

[0103] namespace: "User namespace" # The namespace where the user resides

[0104] name: "Username" # User's name

[0105] The AccessPolicy section represents the access permission declaration for a specific tenant (this tenant). This declaration includes "from" and "to" parts. The "from" part declares which source tenants with the specified tenant name can access this tenant, and which resources within this tenant's premises can these source tenants access without explicit declaration. This part can be set as optional; if no tenant name is specified, other tenants cannot access this tenant's resources without explicitly declaring access permissions. This declaration can use `tenants` to specify other tenants allowed to access this tenant's resources, with `*` representing all tenants; or use `resources` as a GVK array, representing the publicly disclosed resource group, version, and kind information, with `*` representing all resources.

[0106] The "to" part declares the permissions granted to this tenant, specifying the name of the destination tenant that this tenant is allowed to access. This part of the declaration can be set to optional; that is, the name of the destination tenant that this tenant is allowed to access can be specified or omitted. If the name of the destination tenant is not specified, the tenant defaults to having permissions only within its own tenant, and the platform will automatically add the configuration -tenants:["tenant's name"] to enable access permissions to resource objects within this tenant. This part of the declaration can use `tenants` to specify the list of destination tenants to be accessed, with * representing all tenants; and can use `accounts` to declare the scope of accounts for which permissions apply, supporting two account types: serviceAccount and user, corresponding to the ServiceAccount and User types in Kubernetes, respectively. Furthermore, the `accounts` declaration can be set to optional; if not specified, it defaults to applying to all accounts within this tenant.

[0107] It is understood that the baseline declaration model described above is only one implementation method of this embodiment, and this embodiment is not limited to it, as long as it can declare the access permissions of tenants. In addition, more or coarser-grained permission configurations can be performed as needed. For example, different allowed resources can be configured for different source tenants, and different service accounts can be configured for different destination tenants.

[0108] During the publication of the access permission information declared above, the publishing module can create an ERBAC object instance based on the AccessPolicy configuration. The ERBAC object instance supplements the authentication capabilities of the RBAC object, working together with the RBAC object to manage access permissions for resource access requests. The content of the ERBAC object instance is consistent with the declaration model described above, and will not be repeated here.

[0109] In the multi-tenant access control method provided in this embodiment, each tenant is configured with permissions to access other tenants and permissions to allow other tenants to access. After a user of a tenant initiates a resource access request to the apiserver, the initiating tenant of the resource access request can be determined first based on the service account attached to the resource access request. Then, based on the permission configuration information of the initiating tenant and the identity information of the service account, the destination tenant for the resource access request initiated by the client of the initiating tenant and attached to the service account can be determined. This achieves a coarse screening function for the destination tenant of the resource access request, limiting the destination tenant of the resource access request to the permission configuration information of the initiating tenant. Thus, before the apiserver performs permission control on the resource access request, tenant-level permission verification is performed, thereby realizing the resource isolation function based on tenant granularity. Furthermore, the process of achieving resource isolation does not require modification of tenant information, making it more universally applicable. At the same time, this multi-tenant access control method can control and manage multiple tenants based on the same control center, meaning that multiple tenants can share basic resource facilities without creating a corresponding control plane or Kubernetes cluster for each tenant, which improves the utilization of cluster resources and reduces resource waste. It does not affect the architecture and mode of other components in the Kubernetes cluster, making system operation and maintenance easier.

[0110] In some embodiments, the initiating tenant of a resource access request can be determined based on the tenant affiliation information of the service account, such as... Figure 4 As shown, step S2 above may include the following processing: step S21, querying the tenant affiliation information of the service account from the environment configuration information; the environment configuration information includes the tenant affiliation information of each service account; step S22, determining the initiating tenant that initiates the resource access request based on the tenant affiliation information of the service account.

[0111] The environment configuration information can be understood as the configuration information of the cloud service's runtime environment. The service account, as a native object, has its metadata stored within the environment configuration information. The service account's tenant affiliation information identifies the tenant to which the service account belongs, i.e., the tenant that can access the service account; this information can be stored as metadata for the service account. Subsequently, the initiating tenant of the resource access request can be determined based on the service account attached to the resource access request.

[0112] In practical applications, there can be multiple service accounts. In this embodiment, tenant affiliation information is configured for each service account. When a tenant sends a resource access request to the apiserver through a client, it must attach the service account belonging to that tenant; otherwise, the resource access request will be considered as having no access permission and will be intercepted by the front-end proxy module. In this way, service accounts can be divided based on tenants, achieving resource isolation at the tenant level for service accounts. This prevents a service account from indiscriminately accessing multiple supported tenants, thus avoiding the problem of excessive access permissions.

[0113] Specifically, before determining the initiating tenant of a resource access request, the tenant affiliation information of each service account can be parsed during the resource object publication process corresponding to the service account. Then, this tenant affiliation information is added to the service account's metadata. In this way, the initiating tenant can be determined based on the service account carried in the access request, making the tenant determination process more convenient. For example, a tenant tag can be added to the metadata tags of each service account, representing the tenant to which that service account belongs. The tenant tag can take the form of, but is not limited to, the following: metadata.xcloud.com / tenant.

[0114] Furthermore, tenant tags can be added through the publishing module described above. Specifically, during the native object publishing process, the publishing module can parse out the tenant to which each service account belongs and add the aforementioned tenant tags to the metadata tags of each service account.

[0115] It is understood that configuring the tenant affiliation information of the service account by adding tags as described above is only one implementation method of this embodiment. This embodiment is not limited to this. For example, a configuration information list of the service account can also be set up, and tenant affiliation information can be added, deleted, and modified by updating the list.

[0116] In other embodiments, the destination tenant with which the resource access request has permission can be determined based on the permission configuration information of the initiating tenant and the specific service account to which the resource access request is attached. Specifically, for example... Figure 5 As shown, step S3 above may include the following processing: step S31, determining the first destination tenant that the initiating tenant has permission to access based on the permission configuration information; step S32, filtering out the second destination tenant that has permission to access the resource access request from the first destination tenant based on the service account.

[0117] The initiating tenant can have multiple destination tenants with access permissions, so there can also be multiple primary destination tenants. Specifically, caching can be done in a list format, but is not limited to.

[0118] In this embodiment, the permission configuration information of the initiating tenant not only specifies the target tenant that the initiating tenant can access, but also declares the scope in which the permission can be effective. That is, not all resource access requests initiated by the initiating tenant can access the specified target tenant, but only the service account and tenant specified in the permission configuration information can access the specified target tenant. Therefore, after determining the first target tenant that the initiating tenant can access, a second target tenant that the service account attached to the resource access request has permission to access can be further selected from the first target tenant based on the service account attached to the resource access request.

[0119] It is understandable that each tenant's permission configuration information may include one or more sets of restriction information, each set of restriction information being used to limit access permissions to one or more types of resource information.

[0120] In other embodiments, after determining that the destination tenant for which the resource access request has permission to access it, the resource access request can be modified or verified according to different access types. Specifically, such as... Figure 6 As shown, after step S3 above, the multi-tenant access control method may further include the following processing: step S4, determining the target resource object requested by the resource access request; step S5, if the target resource object contains list information, adding destination tenant identification information to the request parameters of the resource access request; or, step S6, if the target resource object does not contain list information, intercepting resource access requests whose tenant does not belong to the destination tenant.

[0121] The target resource object can be understood as the target resource that the resource access request seeks to access. This target resource includes data resources and operational resources, and can be resources owned by other tenants, resources within the current tenant, or other service resources on the cloud service. The destination tenant tag is used to identify the destination tenant that the resource access request has permission to access. It is important to understand that the destination tenant that the resource access request has permission to access is determined based on the permission configuration information of the initiating tenant, not the actual destination tenant that the resource access request points to or actually wants to access.

[0122] In practical applications, the target tenant that the resource access request initiated by the initiating tenant actually wants to access is not necessarily the target tenant configured in the permission configuration information of the initiating tenant, i.e. the target tenant that has permission to access. Based on this situation, this embodiment first determines the target tenant that the resource access request has permission to access, and performs preprocessing on the resource access request according to the type of the resource access request and whether the resource access request actually has permission to access the target tenant it actually points to.

[0123] This preprocessing can perform two processing steps for different resource access requests. First, if the resource access request includes a list request, it can be understood as a batch request. Instead of determining the actual target tenant of each resource access request, the target tenant identification information can be added directly to the request parameters of the resource access request. Second, if the resource access request includes a single request, resource access requests whose target resource object belongs to a tenant that does not belong to the target tenant can be intercepted.

[0124] List requests represent requests to access multiple destination tenants, while single requests represent requests to access only one destination tenant.

[0125] In this embodiment, when the resource access request is a list request, the apiserver can perform authentication, authorization, and access control on the destination tenant carried in the request parameters. This not only achieves tenant-level group member isolation but also narrows the authentication scope of the apiserver, effectively reducing its workload. When the resource access request is a single request, the tenant to which the target resource object belongs can be determined first, i.e., the actual destination tenant to which the resource access request is intended. Then, the tenant to which the target resource object belongs is verified. If the tenant to which the target resource object belongs is the destination tenant declared in the initiating tenant's permission configuration information, the resource access request is allowed and forwarded to the apiserver, where it can perform the authentication process. If the tenant to which the target resource object belongs is not the destination tenant declared in the initiating tenant's permission configuration information, the resource access request is intercepted, and a 401 status code is returned to the client.

[0126] Specifically, if the target resource object is a list request, the step of adding destination tenant identification information to the request parameters of the resource access request can include the following processing: determining the query parameters of the resource access request; adding the tenant name of each destination tenant to the selector label (labelSelector) of the query parameters. In this way, by modifying the labelSelector, the scope of destination tenants with permissions can be filtered to ensure that the access request has access to resource objects of some tenants.

[0127] The query parameter can be understood as the query parameter of the access request, which is a part of the URL (Uniform Resource Locator) information of the access request.

[0128] For list requests, such as list watch requests, you can first determine the query parameters of the list watch request, and then add the target tenant range option on top of the original LabelSelector tag. The tag for adding the target tenant range looks like this:

[0129] metadata.xcloud.com / tenant in(tenant1,tenant2,tenant3).

[0130] It should be noted that in practical applications, some access requests may not carry selector tags. In such cases, selector tags can be added to the request parameters of such access requests, along with the tenant name of each destination tenant.

[0131] For a single request, such as a GET request, UPDATE request, PATCH request, or DELETE request, the target resource object information can be extracted from the URL. The system can then query the environment configuration information for existing destination tenants based on the target resource object information, and further determine the target service account corresponding to the destination tenant containing the target resource object. If the tenant to which the target service account belongs exists in the list of tenants allowed to access the resource, i.e., the tenant name in the metadata.xcloud.com / tenant tag of the target service account exists in the list of tenants (tenant1, tenant2, tenant3) allowed to access the resource, then the resource access request can be sent to the API server. Otherwise, the resource access request is intercepted, and a 401 status code is returned to the client.

[0132] Specifically, this embodiment can also perform the above-mentioned preprocessing process only for some resource access requests with high request frequency, such as the list watch request, get request, update request, patch request and delete request mentioned above. For other types of resource access requests, such as those with low access frequency, the preprocessing process can be omitted, and the requests can be directly forwarded to the backend Kubernetes apiserver module, relying on the RBAC mechanism inside the apiserver module to complete the permission control process.

[0133] The aforementioned access control process may include, but is not limited to, the authentication process, authorization process, and admission control process. The authentication process includes: receiving a resource access request from a client, verifying the identity credentials (e.g., API key, token, or certificate) in the request, and allowing the request to proceed to the authorization process upon successful verification. The authorization process includes: determining whether to authorize the request based on the identity information and access permissions contained in the request. If the request is authorized, a response is returned or a corresponding operation is performed; both the response data and the operation can be referred to as the target resource object. If the request is not authorized, an error message is returned or access is denied. After the authorization phase, an admission control process may be required to ensure that the request does not negatively impact the system or meet specific security policies. This admission control process may include checking request frequency, traffic limits, and load balancing.

[0134] It should be noted that the specific processes of the above authentication, authorization, and access control procedures can refer to the standard Kubernetes RBAC process, and will not be elaborated here. This interface service module can include, but is not limited to, the apiserver mentioned above, as long as it can implement permission control for resource access requests.

[0135] In another embodiment, the multi-tenant access control method further includes a permission management process, such as... Figure 7 As shown, the specific processing may include the following steps: Step S7, when the resource access request is a list request, permission control is performed on the resource access request based on the destination tenant to which the resource access request has permission; Step S8, when the resource access request is a single request, permission control is performed on the resource access request based on the destination tenant to which the target resource object belongs.

[0136] In this embodiment, corresponding access control can be implemented based on different resource access requests. Specifically, when a resource access request is a list request, without any limiting conditions, the range of destination tenants corresponding to the request is large. However, the destination tenants that the initiating tenant can access are limited, as are the destination tenants that the service account attached to the request. This limited range refers to the destination tenants that the resource access request has permission to access. Therefore, the identity credentials of the resource access request can be verified selectively within the already determined destination tenants that the resource access request has permission to access, without needing to authenticate all tenants across the entire environment. This shortens the authentication chain, reduces the workload of the API server, and improves the processing efficiency of resource access requests. When the target resource object does not contain list information, authentication can be more targeted at the target tenant to which the target resource object belongs, further shortening the authentication chain and improving the efficiency of access control processing.

[0137] Access control may include, but is not limited to, the authentication process, authorization process, and admission control process described above. The authentication process includes receiving a resource access request from a client, verifying the identity credentials (e.g., API keys, tokens, or certificates) in the request, and allowing the request to proceed to the authorization process upon successful verification. The authorization process involves determining whether to authorize the request based on the identity information and access permissions contained in the request. If the request is authorized, a response is returned or a corresponding operation is performed; both the response data and the operation can be referred to as the target resource object. If the request is not authorized, an error message is returned or access is denied. After authorization, an admission control process may be required to ensure that the request does not negatively impact the system or meet specific security policies. This admission control process may include checking request frequency, traffic limits, and load balancing.

[0138] It should be noted that the specific processes of the above authentication, authorization, and access control procedures can refer to the standard Kubernetes RBAC process, and will not be elaborated here. This interface service module can include, but is not limited to, the apiserver mentioned above, as long as it can implement permission control for resource access requests.

[0139] Furthermore, this access control method can also add tenant ownership information to the target resource object of the resource access request. Specifically, in the access control phase of permission management, when the request type of the resource access request is a write request, tenant ownership information can be added to the target resource object.

[0140] The access control phase can be understood as the phase in which the above access control process is executed.

[0141] In this embodiment, for resource access requests of the write request type, the tenant information can be located through the corresponding service account, and then the corresponding tenant ownership information can be added to the target resource object requested. In this way, by using the tenant information location and resource object topology of ServiceAccount, automated management is realized, and accurate tenant information location and access control capabilities of resources are provided.

[0142] Specifically, webhook technology can be used. First, configure MutatingWebhookConfiguration to forward all resource access requests to the webhook service. Then, the webhook service can execute the following process to add corresponding tenant affiliation information to the target resource object. The specific process includes: 1) The webhook service can parse various data of the resource access request (including access data and response data) and extract userInfo from the parsed AdmissionReview data to determine the service account to which the resource access request belongs; 2) After determining the service account information, the metadata information of the corresponding service account can be read from the environment configuration information to determine the initiating tenant of the resource access request; 3) After determining the initiating tenant of the resource access request, the tenant affiliation information tag can be added to the target resource object corresponding to the resource access request. This tenant affiliation tag can be added using JsonPatch.

[0143] MutatingWebhookConfiguration is a resource type in Kubernetes used to configure mutating webhooks. Mutating webhooks are a Kubernetes API extension that allows users to automatically modify Kubernetes objects before they are created or updated. MutatingWebhookConfiguration allows administrators to define webhook configurations, including the webhook's URL, service certificate, selectors, and rules. Mutating webhooks enable custom automation operations, such as automatically adding tags, annotations, or modifying object specifications.

[0144] AdmissionReview data is the format of request and response data processed by the Admission Control plugin in Kubernetes. It is used to validate, transform, or extend Kubernetes API objects. When creating, updating, or deleting Kubernetes resources, AdmissionReview data is used by the Admission controller to perform corresponding validation and modification operations. "UserInfo" information refers to user information, which may include the user's name, address, etc. JsonPatch is a format and protocol for describing and applying changes to JSON documents. It allows clients to send a set of operations to the server to modify JSON documents, such as adding, deleting, replacing, or moving.

[0145] The following example uses a real baseline configuration, combined with the attached... Figure 8 The specific process of the multi-tenant access control method provided in this embodiment will be explained in detail.

[0146] A specific baseline configuration example is shown below:

[0147] AccessPolicy: # Defines the access policy

[0148] from: # Define which tenants can access which resources of this tenant.

[0149] -tenants:["*"] # Defines that all tenants have permission to access this tenant.

[0150] resources: # Defines which resources within this tenant can be exposed to the outside world.

[0151] -groups:[]# This option sets the number of resource groups that can be publicly accessed to be empty.

[0152] versions:['v1']# The version of the resource that can be made public is v1.

[0153] kinds:['ConfigMap']# The resource type that can be exposed externally is 'Variable Application Management Configuration'.

[0154] to: # Define which service accounts of "this tenant" can access resources within which tenants.

[0155] -tenants:["other-tenant-2","other-tenant-3"] # This tenant can access destination tenants "other-tenant-2" and "other-tenant-3".

[0156] accounts: # Defines the service accounts for which this tenant is granted permissions.

[0157] -serviceAccount:#Service account configuration

[0158] namespace:default # The default namespace for the service account

[0159] name:sa1# The service account name is sa1

[0160] The above configuration declares:

[0161] All other tenants can access the ConfigMap object within this tenant. For the default / sa1 service account within this tenant, grant tenant access permissions to other tenants -2 and -3.

[0162] The following release process will be followed first:

[0163] The baseline declaration definition must be processed by the release module and submitted to runtime to take effect. During the release process, the release module will parse the baseline and create the relevant access control objects. In this solution, access control will be handled jointly by native RBAC and the extended ERBAC. The activation process is as follows:

[0164] a. The publishing module submits the RBAC native objects used by each tenant in the dedicated cloud baseline, such as ServiceAccount, Role, Rolebinding, ClusterRole, and ClusterRoleBinding. In this embodiment, during the object publishing process, the publishing module can parse out the tenant to which the object belongs and add the metadata.xcloud.com / tenant tag to the tags of each published object to represent the tenant to which the object belongs.

[0165] b. The deployment module parses the baseline and creates an ERBAC object for the AccessPolicy configuration as a supplement to RBAC capabilities. The ERBAC object maintains the same model as the access process described above. For example, the baseline configuration instance above can generate the following ERBAC object:

[0166] apiVersion:multi-tenant.xcloud.com / v1alpha1 # Defines the resource and version information of the ERBAC object.

[0167] kind:ERBAC# Defines the resource type

[0168] spec:#Configuration

[0169] from: # Define which tenants can access which resources of "this tenant".

[0170] -tanents:["*"] # Defines which tenants have permission to access this tenant.

[0171] resources: # Defines which permissions within this tenant are open to external access - groups: [] # Defines resource groups that can be accessed externally

[0172] versions:['v1']#Resource version

[0173] kinds:['ConfigMap']#Resource type

[0174] to: # Define which service accounts of "this tenant" can access resources within which tenants.

[0175] -tanents:["other-tenant-2","other-tenant-3"]# The destination tenants that this tenant can access.

[0176] accounts: # Defines the service accounts for which this tenant is granted permissions.

[0177] -serviceAccount:#Service account configuration

[0178] namespace:default # The namespace where the service account resides

[0179] name:sa1#The name of the service account

[0180] The meaning of each configuration information in the above ERBAC objects is as described in their corresponding baseline instances, and will not be repeated here.

[0181] Then the runtime process is executed, as follows:

[0182] a. Front-end Proxy Deployment: By deploying a front-end proxy on the Kubernetes master node, listening on the port originally bound to the Kubernetes apiserver, traffic interception is achieved. Based on the front-end proxy's need for modifying and verifying requests and responses, Caddy proxy can be used as the front-end proxy. Caddy is an extensible front-end proxy that supports adding request verification and modification functionality through plugins.

[0183] b. Client requests resource objects: Tenants can mount a ServiceAccount object on their client and initiate resource access requests to the Kubernetes apiserver. The request parameters of this resource access request will automatically carry the ServiceAccount object information. When performing permission control later, the relevant information of the ServiceAccount object can be used for verification.

[0184] c. When a request reaches the front-end proxy, it undergoes pre-processing before being forwarded to the Kubernetes apiserver module to control multi-tenant permissions. The specific processing flow is as follows:

[0185] First, the ServiceAccount object information carried in this resource access request is parsed. This information can be extracted from the certificate information or JWT (JSON Web Token) information carried in the request. After parsing the ServiceAccount, the front-end proxy will query the corresponding ServiceAccount object in the environment. The metadata.xcloud.com / tenant tag of this object represents the tenant to which the ServiceAccount belongs. At this point, the tenant that initiated this resource access request is determined.

[0186] ii. After identifying the tenant initiating this resource access request, query the existing ERBAC objects in the environment to filter out the list of other tenants allowed to access the resource. Since the ERBAC object declares the access permission information of the source and destination tenants, the target permissions possessed by the initiating tenant of this resource access request can be retrieved. For example, we can assume that the list of destination tenants allowed to access the resource is (tenant1, tenant2, tenant3).

[0187] iii. After determining the list of allowed tenants, the front-end proxy can modify or validate requests for different access types. The process is as follows:

[0188] 1. For list watch requests, the labelSelector can be modified to filter the scope of tenants with the necessary permissions, thus narrowing the access permissions of the list watch request to a subset of tenants. The specific implementation method is as follows: For the query parameter of the request, add a tenant scope option above the existing LabelSelector (if it does not exist, add the LabelSelector configuration manually): metadata.xcloud.com / tenant in(tenant1,tenant2,tenant3).

[0189] 2. For GET, UPDATE, PATCH, and DELETE requests, the target resource object of the current resource access request can be extracted. This target resource object can then be pre-validated using an ERBAC object to ensure sufficient access permissions. The specific implementation is as follows: Based on the URL information, extract the information of the target resource object accessed in this request. Then, query the tenant to which the target resource object belongs in the environment based on this information. If the tenant information tag metadata.xcloud.com / tenant on the target resource object exists in the list of allowed target tenants (tenant1, tenant2, tenant3), the resource access request is allowed (forwarded to the interface service module for permission control). Otherwise, the resource access request is intercepted, and a 401 status code is returned.

[0190] i. For other types of requests, the front-end proxy can leave them unprocessed and forward them directly to the back-end Kubernetesapiserver module, relying on its internal RBAC authorization and other processes to complete permission control. The specific control process is as follows:

[0191] a. The Kubernetes apiserver module receives resource access request information and uses native RBAC capabilities to perform the authorization process.

[0192] b. Adding tenant ownership information for objects during the admission control phase: For write requests, such as CREATE requests, MutatingWebhookConfiguration can be configured to forward all resource access requests and their response data or response operations to the webhook service. The webhook service can then execute the following process:

[0193] i. Parse response data: Extract userInfo information from the requested AdmissionReview data to determine the ServiceAccount to which this resource access request belongs.

[0194] ii. After determining the ServiceAccount information, read the corresponding ServiceAccount object from the environment to identify the initiating tenant of this resource access request. The specific method for confirming the initiating tenant is as follows: read the metadata.xcloud.com / tenant tag of the ServiceAccount, and determine the initiating tenant based on the tenant information in the tag.

[0195] iii. After obtaining the tenant that initiated this resource access request, add a tenant ownership label to the target resource object to be operated on: Specifically, the tenant ownership label can be added using JsonPatch: {"op":"add","path":" / metadata / labels / metadata.xcloud.com / tenant","value":"tenant information"}.

[0196] Some embodiments of this application also provide a multi-tenant access control apparatus for executing the multi-tenant access control method provided in any of the above embodiments. Figure 9 A schematic diagram of the multi-tenant access control device is shown, such as... Figure 9 As shown, the multi-tenant access control device includes:

[0197] The service account determination module is used to respond to resource access requests sent by clients and determine the service account corresponding to the resource access requests.

[0198] The initiating tenant determination module is used to determine the initiating tenant that initiates the resource access request based on the service account;

[0199] The destination tenant determination module is used to determine the destination tenant that the resource access request has permission to access based on the permission configuration information and service account of the initiating tenant. The permission configuration information of the initiating tenant is used to declare the destination tenants that the initiating tenant is allowed to access, as well as the service accounts that access each destination tenant.

[0200] It is understood that the multi-tenant access control device provided in this embodiment and the multi-tenant access control method provided in this application embodiment are based on the same inventive concept and have at least the same beneficial effects as the methods they adopt, operate or implement. Furthermore, various implementation methods of the multi-tenant access control method embodiment are also applicable to the embodiment of this multi-tenant access control device.

[0201] Specifically, the tenant determination module can first query the tenant affiliation information of service accounts from the environment configuration information; the environment configuration information includes the tenant affiliation information of each service account; then, based on the tenant affiliation information of the service accounts, it determines the initiating tenant that initiates the resource access request. The tenant affiliation information of the service accounts is used to characterize the tenant to which the served account belongs.

[0202] The destination tenant determination module can first determine the first destination tenant that the initiating tenant has permission to access based on the permission configuration information; then, based on the service account, it can filter out the second destination tenant that the resource access request has permission to access from the first destination tenant.

[0203] In some embodiments of this application, the multi-tenant access control device may further include a permission preprocessing module, which may be used to: determine the target resource object requested by the resource access request; if the target resource object contains list information, add destination tenant identification information to the request parameters of the resource access request, wherein the destination tenant's label is used to characterize the destination tenant to which the resource access request has permission; or, if the target resource object does not contain list information, intercept resource access requests whose tenant does not belong to the destination tenant.

[0204] Specifically, the permission preprocessing module can first determine the query parameters of the resource access request; then add the tenant name of each destination tenant to the selector tag of the query parameters.

[0205] In some embodiments of this application, the multi-tenant access control device may further include a permission control module, which can be used to: control the permission of resource access requests based on the destination tenant to which the resource access request has permission when the target resource object contains list information; and control the permission of resource access requests based on the destination tenant to which the target resource object belongs when the target resource object does not contain list information.

[0206] Specifically, this access control module can also be used to add tenant ownership information to the target resource object when the resource access request type is a write request during the access control phase of access control.

[0207] In some embodiments of this application, the multi-tenant access control device may further include a tenant information configuration module, which is used to parse the tenant affiliation information of each service account during the resource object publishing process corresponding to the service account; add the tenant affiliation information of the service account to the metadata information of the service account; and store the metadata information of the service account in the environment configuration information.

[0208] Specifically, the tenant information configuration module may include, but is not limited to, the aforementioned publishing module, as long as it can parse and add tenant ownership information.

[0209] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0210] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative, and the modules described as separate components may or may not be physically separate. The components illustrated as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0211] Some embodiments of this application also provide a multi-tenant access control system, applied to cloud platforms in multi-tenant scenarios, such as... Figure 2 As shown, the system may include an interface service module and a front-end proxy module. The front-end proxy module is used to intercept resource access requests sent by the client to the interface service module and determine the service account corresponding to the resource access request. Based on the service account, it determines the initiating tenant that initiated the resource access request. Based on the permission configuration information and service account of the initiating tenant, it determines the destination tenant that the resource access request has permission to access. The interface service module executes the permission management process for the resource access request based on the destination tenant that the resource access request has permission to access.

[0212] It is understood that the multi-tenant access control device provided in this embodiment and the multi-tenant access control method provided in this application embodiment are based on the same inventive concept and have at least the same beneficial effects as the methods they adopt, operate or implement. Furthermore, various implementation methods of the multi-tenant access control method embodiment are also applicable to the embodiment of this multi-tenant access control device.

[0213] Specifically, the front-end proxy module can first query the tenant affiliation information of service accounts from the environment configuration information; the environment configuration information includes the tenant affiliation information of each service account; then, based on the tenant affiliation information of the service accounts, it determines the initiating tenant that initiates the resource access request. The tenant affiliation information of the service accounts is used to characterize the tenant to which the served account belongs.

[0214] The destination tenant determination module can first determine the first destination tenant that the initiating tenant has permission to access based on the permission configuration information; then, based on the service account, it can filter out the second destination tenant that the resource access request has permission to access from the first destination tenant.

[0215] In some embodiments of this application, the front-end proxy module can also be used to: determine the target resource object requested by the resource access request; if the target resource object contains list information, add destination tenant identification information to the request parameters of the resource access request, wherein the destination tenant's tag is used to characterize the destination tenant that the resource access request has permission to access; or, if the target resource object does not contain list information, intercept resource access requests whose tenant does not belong to the destination tenant.

[0216] Specifically, the front-end proxy module can first determine the query parameters of the resource access request; then add the tenant name of each destination tenant to the selector label of the query parameters.

[0217] In some embodiments of this application, the interface service module can be specifically used to: when the target resource object contains list information, to control the access permissions of the resource access request based on the destination tenant to which the resource access request has permission; when the target resource object does not contain list information, to control the access permissions of the resource access request based on the destination tenant to which the target resource object belongs.

[0218] Specifically, this interface service module can also be used to add tenant ownership information to the target resource object when the resource access request type is a write request during the access control phase of permission management.

[0219] In some embodiments of this application, the multi-tenant access control system may further include a publishing module, which is used to publish each resource object, and during the resource object publishing process corresponding to the service account, parse the tenant affiliation information of each service account; and add the tenant affiliation information of the service account to the metadata information of the service account; the metadata information of the service account is stored in the environment configuration information.

[0220] The implementation process of the functions and roles of each module in the above system is detailed in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0221] For the system embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative, wherein the modules described as separate components may or may not be physically separate, and the components illustrated as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0222] This application also provides an electronic device corresponding to the multi-tenant access control method provided in the foregoing embodiments, for executing the multi-tenant access control method described above.

[0223] It is understood that when the electronic device performs the above-mentioned step S6 and the steps before it, the electronic device may include the above-mentioned front-end agent module (or front-end agent server), and when it also performs the above-mentioned permission control steps after step S6, the electronic device may include the above-mentioned multi-tenant access control system.

[0224] Please refer to Figure 10 This illustrates a schematic diagram of the hardware structure of an electronic device provided by some embodiments of this application. For example... Figure 10 As shown, the electronic device 10 includes: a processor 100, a memory 101, a bus 102, and a communication interface 103, wherein the processor 100, the communication interface 103, and the memory 101 are connected via the bus 102; the memory 101 stores a computer program that can run on the processor 100, and when the processor 100 runs the computer program, it executes the multi-tenant access control method or multi-tenant access control method provided in any of the foregoing embodiments of this application.

[0225] The memory 101 can be any electronic, magnetic, optical, or other physical storage device, and can contain stored information such as executable instructions, data, etc. Specifically, the memory 101 can be RAM (Random Access Memory), flash memory, a storage drive (such as a hard disk drive), any type of storage disk (such as an optical disc, DVD, etc.), or similar storage media, or a combination thereof. Communication between this device network element and at least one other network element is achieved through at least one communication interface 103 (which can be wired or wireless), and the Internet, wide area network, local area network, metropolitan area network, etc., can be used.

[0226] Bus 102 can be an ISA bus, PCI bus, or EISA bus, etc. Buses can be divided into address buses, data buses, control buses, etc.

[0227] Processor 100 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 100 or by instructions in software form. Processor 100 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), Application-Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 101. The processor 100 reads the information in memory 101 and, in conjunction with its hardware, completes the steps of the above method.

[0228] The electronic device provided in this application embodiment and the multi-tenant access control method or multi-tenant access control method provided in this application embodiment are based on the same inventive concept and have the same beneficial effects as the methods they adopt, operate or implement.

[0229] This application also provides a computer-readable storage medium corresponding to the multi-tenant access control method or multi-tenant access control method provided in the foregoing embodiments. Please refer to... Figure 11 The computer-readable storage medium shown is an optical disc 110, on which a computer program (i.e., a program product) is stored. When the computer program is run by a processor, it executes the multi-tenant access control method or multi-tenant access control method provided in any of the foregoing embodiments.

[0230] It should be noted that examples of computer-readable storage media may also include, but are not limited to, phase-change memory (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 optical and magnetic storage media, which will not be elaborated here.

[0231] This application also provides a computer program product, including a computer program that is executed by a processor to implement the multi-tenant access control method or the multi-tenant access control method of any of the above embodiments.

[0232] The computer-readable storage medium and computer program product provided in the above embodiments of this application are based on the same inventive concept as the multi-tenant access control method or multi-tenant access control method provided in the embodiments of this application, and have the same beneficial effects as the methods adopted, run or implemented by the application stored therein.

[0233] It should be noted that:

[0234] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known structures and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0235] Similarly, it should be understood that, in order to simplify this application and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of this application, various features of this application are sometimes grouped together in a single embodiment, figure, or description thereof. However, this disclosure should not be construed as reflecting a schematic diagram in which the claimed application requires more features than those expressly recited in the various claims. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of this application.

[0236] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are intended to be within the scope of this application and form different embodiments. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[0237] The above are merely preferred embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A multi-tenant access control method, characterized in that, The method, applied to a server-side front-end proxy module, includes: Receive a resource access request sent by any tenant's client and determine the identity information in the service account to which the resource access request is attached; The tenant that initiated the resource access request is determined based on the identity information in the service account. Based on the permission configuration information of the initiating tenant and the identity information in the service account, the destination tenant that the resource access request has permission to access is determined. The permission configuration information of the initiating tenant is used to declare the destination tenant that the initiating tenant is allowed to access and the service account that accesses each destination tenant.

2. The method according to claim 1, characterized in that, The step of determining the initiating tenant who initiated the resource access request based on the service account includes: The service account's tenant affiliation information is retrieved from the environment configuration information. The service account's tenant affiliation information is used to characterize the tenant to which the service account belongs. Based on the tenant affiliation information of the service account, the initiating tenant that initiated the resource access request is determined.

3. The method according to claim 1, characterized in that, The step of determining the destination tenant with permission to access the resource based on the permission configuration information of the initiating tenant and the service account includes: Based on the permission configuration information, the first destination tenant that the initiating tenant has permission to access is determined; Based on the service account, a second destination tenant with the permission to access the resource access request is selected from the first destination tenant.

4. The method according to any one of claims 1-3, characterized in that, After determining the destination tenant with permission to access the resource based on the initiating tenant's permission configuration information and the service account, the process further includes: Determine the target resource object requested by the resource access request; When the resource access request is a list request, destination tenant identification information is added to the request parameters of the resource access request. The list request indicates that the request is for access to multiple destination tenants, and the destination tenant identification information is used to identify the destination tenants that the resource access request has permission to access; or... In the case that the resource access request is a single request, resource access requests from tenants to which the target resource object belongs that are not the destination tenant are intercepted. The single request indicates that the request is to access a destination tenant.

5. The method according to claim 4, characterized in that, Adding destination tenant identification information to the request parameters of the resource access request includes: Determine the query parameters of the resource access request; Add the tenant name of each destination tenant to the selector label of the query parameters.

6. The method according to claim 4, characterized in that, The method further includes: When the resource access request includes a list request, the access control for the resource access request is performed based on the destination tenant who has the permission to access the resource. When the resource access request includes a single request, the access control for the resource access request is performed based on the destination tenant to which the target resource object belongs.

7. The method according to claim 6, characterized in that, The method further includes: During the access control phase of the permission management, if the request type of the resource access request is a write request, tenant ownership information is added to the target resource object.

8. The method according to any one of claims 1-3, characterized in that, Before determining the initiating tenant who initiated the resource access request based on the service account, the method further includes: During the resource object publishing process corresponding to the service account, the tenant affiliation information of each service account is parsed. The tenant affiliation information of the service account is added to the metadata information of the service account; the metadata information of the service account is stored in the environment configuration information.

9. A multi-tenant access control device, characterized in that, The device includes: The service account determination module is used to respond to a resource access request sent by the client and determine the service account corresponding to the resource access request; The initiating tenant determination module is used to determine the initiating tenant who initiated the resource access request based on the service account. The destination tenant determination module is used to determine the destination tenant that the resource access request has permission to access based on the permission configuration information of the initiating tenant and the service account; the permission configuration information of the initiating tenant is used to declare the destination tenants that the initiating tenant is allowed to access, as well as the service accounts that access each destination tenant.

10. A multi-tenant access control system, characterized in that, A cloud platform applied in a multi-tenant scenario, the multi-tenant access control system includes an interface service module and a front-end agent module; The front-end proxy module is used to intercept resource access requests sent by any tenant's client to the interface service module, and to determine the identity information in the service account attached to the resource access request. The tenant that initiated the resource access request is determined based on the identity information in the service account. Based on the permission configuration information of the initiating tenant and the identity information in the service account, the destination tenant that the resource access request has permission to access is determined. The permission configuration information of the initiating tenant is used to declare the destination tenant that the initiating tenant is allowed to access and the service account that accesses each destination tenant. The interface service module performs an access control process on the resource access request based on the destination tenant that has permission to access the resource.

11. The system according to claim 10, characterized in that, In the access control phase of the permission management process, when the request type of the resource access request is a write request, the interface service module adds tenant ownership information to the target resource object corresponding to the resource access request.

12. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the method as described in any one of claims 1-8.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the method as described in any one of claims 1-8.

14. A computer program product, comprising a computer program, characterized in that, The computer program is executed by a processor to implement the method according to any one of claims 1-8.

Images