Method and apparatus for cluster permission management, and first node, storage medium and computer program product

Abstract

Disclosed in the present application are a method and apparatus for cluster permission management, and a first node, a storage medium and a computer program product. The method comprises: a first node receiving a first request, wherein the first request is triggered on a first user interface of the first node and is used for requesting management and / or viewing of permissions of one or more cross-domain clusters; and by means of invoking a configuration component of each cluster corresponding to the first request, executing, on each cluster corresponding to the first request, a configuration operation corresponding to the first request.

Description

Cluster access control methods, devices, first nodes, storage media, and computer program products

[0001] Cross-reference to related applications

[0002] This application is based on and claims priority to Chinese Patent Application No. 202411996718.0, filed on December 30, 2024, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of big data technology, and in particular to a cluster permission management method, device, first node, storage medium and computer program product. Background Technology

[0004] Currently, with the increase in business and massive amounts of data, enterprises have successively built multiple resource pools, each deploying multiple clusters to meet the usage needs of big data components. Due to the different times when the clusters were built and the complexity of the personnel managing and maintaining the clusters, there are still difficulties in management and maintenance of big data component access control. Summary of the Invention

[0005] To address the related technical issues, embodiments of this application provide a cluster permission management method, apparatus, first node, storage medium, and computer program product.

[0006] The technical solution of this application embodiment is implemented as follows:

[0007] This application provides a cluster permission management method, the method including:

[0008] Receive a first request, which is triggered in the first user interface of the first node, for requesting permission management and / or viewing of one or more cross-domain clusters;

[0009] By invoking the configuration component of each cluster corresponding to the first request, the configuration operation corresponding to the first request is executed on each cluster corresponding to the first request.

[0010] This application embodiment also provides a cluster permission management device, including:

[0011] The first receiving unit is configured to receive a first request, which is triggered by the first user interface of the first node and is used to request the management and / or viewing of permissions for one or more cross-domain clusters.

[0012] The calling unit is configured to execute the set operation corresponding to the first request on each cluster corresponding to the first request by calling the set component of each cluster corresponding to the first request.

[0013] This application also provides a first node, including a processor and a memory configured to store a computer program capable of running on the processor.

[0014] Wherein, the processor is configured to execute the steps of any of the above methods when running the computer program.

[0015] This application also provides a storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of any of the above methods.

[0016] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above methods.

[0017] In the cluster permission management method, apparatus, first node, storage medium, and computer program product provided in this application embodiment, the first node receives a first request, which is triggered in the first user interface of the first node, for requesting permission management and / or viewing of one or more cross-domain clusters; by calling the setting component of each cluster corresponding to the first request, the setting operation corresponding to the first request is executed on each cluster corresponding to the first request. The above solution enables the management and / or viewing of one or more cross-domain clusters by calling the setting component of one or more cross-domain clusters, allowing users to achieve unified management of multiple cross-domain clusters in the first user interface, greatly reducing the difficulty of cluster management and maintenance, reducing the cost of manual maintenance, and improving cluster management efficiency. Attached Figure Description

[0018] Figure 1 is a flowchart illustrating a cluster permission management method according to an embodiment of this application;

[0019] Figure 2 is a schematic diagram of a permission management embodiment of this application;

[0020] Figure 3 is a schematic diagram of a unified access control system according to an embodiment of this application;

[0021] Figure 4 is an example diagram of a first relation representation in an embodiment of this application;

[0022] Figure 5 is a schematic diagram of a sixth information reporting according to an embodiment of this application;

[0023] Figure 6 is an example diagram of an interface encoding type according to an embodiment of this application;

[0024] Figure 7 is a schematic diagram of a second relationship establishment process according to an application embodiment of this application;

[0025] Figure 8 is a flowchart illustrating a cluster permission management method according to an application embodiment of this application;

[0026] Figure 9 is a schematic flowchart of a method for determining fourth information based on first information and first relationship according to an application embodiment of this application;

[0027] Figure 10 is an example diagram of a second user interface according to an application embodiment of this application;

[0028] Figure 11 is a schematic diagram of a cluster permission management device according to an embodiment of this application;

[0029] Figure 12 is a schematic diagram of the first node structure in an embodiment of this application. Detailed Implementation

[0030] In the field of big data, with the dual increase in business volume and massive amounts of data, enterprises will successively build multiple resource pools, each deploying multiple clusters to meet the usage needs of big data components for different tenants and different businesses. Considering security issues, enterprises also need to control and isolate the access permissions of big data components for different tenants or users. However, due to the different times the clusters are built and the complexity of the personnel managing and maintaining them, there are difficulties in the operation and maintenance of big data component access control, and a lack of unified maintenance. To address this problem, independent access management is typically implemented for each cluster, resulting in separate access data views, failing to achieve unified management and visualization, which brings inconvenience to the actual operation and maintenance process.

[0031] Among related technologies, Apache Sentry and Apache Ranger provide big data component permission management functions, which can achieve basic permission control and viewing for a single cluster. However, due to the limitations of the frameworks, these two frameworks cannot provide unified management and unified view of big data components in cross-domain multi-cluster scenarios. That is, the current frameworks can only manage a single cluster and visualize permission data for a single cluster, and cannot achieve cross-domain cluster management and cross-domain multi-cluster visualization.

[0032] Based on this, in various embodiments of this application, a first node receives a first request, which is triggered in the first user interface of the first node, for requesting permission management and / or viewing of one or more cross-domain clusters; by calling the setting component of each cluster corresponding to the first request, the setting operation corresponding to the first request is executed on each cluster corresponding to the first request. The above scheme enables the management and / or viewing of one or more cross-domain clusters by calling the setting component of one or more cross-domain clusters, allowing users to achieve unified management of multiple cross-domain clusters in the first user interface, greatly reducing the difficulty of cluster management and maintenance, reducing the cost of manual maintenance, and improving cluster management efficiency.

[0033] The present application will now be described in further detail with reference to the accompanying drawings and embodiments.

[0034] This application provides a cluster permission management method applied to a first node. The first node can establish connections with permission management nodes (second nodes) on various clusters in various domains, and manage permissions across various clusters across domains through interaction with the permission management nodes on each cluster. The first node can be understood as a unified management node, as shown in Figure 1. The method includes:

[0035] Step 101: Receive the first request.

[0036] The first request is triggered by the first user interface of the first node and is used to request the management and / or viewing of permissions for one or more cross-domain clusters.

[0037] Here, receiving the first request can be achieved by the first node receiving the first request through the unified permission management application programming interface (API). The first request is used to request the management or viewing of permissions for one or more cross-domain clusters, or to request the management and viewing of permissions for one or more cross-domain clusters. For example, the first request may request the deletion of permissions for one or more cross-domain clusters and view the permissions of the deleted one or more cross-domain clusters. The first request includes at least the identifiers of one or more cross-domain clusters or resource pools, and the cluster permission operation type corresponding to the first request. If the first request includes the identifier of a resource pool, the first request is used to request the management and / or viewing of permissions for all clusters under the resource pool corresponding to the resource pool identifier. Managing cluster permissions includes creating or adding permissions, deleting permissions, and modifying permissions.

[0038] Step 102: By calling the configuration component of each cluster corresponding to the first request, execute the configuration operation corresponding to the first request for each cluster corresponding to the first request.

[0039] Here, by invoking the configuration components of each cluster in one or more cross-domain clusters corresponding to the first request, the permissions of each cluster in the one or more cross-domain clusters corresponding to the first request are managed and / or viewed. The cluster configuration components are used to manage and store cluster permissions and provide a Representational State Transfer (REST) ​​API for external devices to call or modify cluster permissions. The configuration operation corresponding to the first request is to manage and / or view cluster permissions. For example, the configuration component can be the ranger admin component.

[0040] It should be noted that before receiving the first request, the first node can pre-manage the permissions of each cluster, that is, centralize the permissions of each cluster for unified management. For example, the Apache Ranger permission management framework can be used to manage the permissions of each cluster of the Hadoop Distributed File System (HDFS). That is, each cluster has a second node with the Apache Ranger ranger admin component deployed. The second node is used to manage and store the permissions, user information, and other information of the cluster where the second node is located, and provides a REST API to allow external devices to obtain or modify the cluster permissions. The configuration plugin in Apache Ranger, namely the ranger plugin, monitors each namespace (NS) in the cluster and dynamically pulls the permissions stored in the ranger admin component in real time. Considering the compatibility issues between big data components and the Apache Ranger framework, and the fact that different versions of permission management frameworks are not fully compatible, and different clusters may use different versions of permission management frameworks, different versions of the Ranger Admin component are deployed on clusters using different versions of permission management frameworks to manage the big data components. For example, as shown in Figure 2, different clusters can use different versions of permission management frameworks, and correspondingly deploy different versions of configuration components, namely the Ranger Admin component (ranger admin 0.5.3, ranger admin 1.1.0, and ranger admin 2.3.0 in Figure 2). The first node can interact with the Ranger Admin component of each cluster to manage the permission-related information of each cluster. As shown in Figure 3, the first node can include a management module, which provides a unified permission management interface to achieve unified permission management for each cluster under each framework.

[0041] In this embodiment, the first node can call the cross-domain multi-cluster setting component to manage and / or view the permissions of the cross-domain multi-cluster, realizing unified management of cluster permissions in cross-domain multi-cluster scenarios; the first user interface can provide an interface for managing and / or viewing the permissions of cross-domain multi-cluster, that is, the first user interface can provide a unified view of cluster permissions in cross-domain multi-cluster scenarios, thereby realizing unified viewing and management of one or more cross-domain clusters on a unified view, improving the flexibility and operability of operation and maintenance, reducing the cost and service level of operation and maintenance, and improving the efficiency of permission management.

[0042] In order to enable cluster permission management and / or viewing through configuration components, in one embodiment, the step of calling the configuration component of each cluster corresponding to the first request to perform the configuration operation corresponding to the first request on each cluster includes:

[0043] Obtain first information and second information from the first request. The first information represents the identifier of the one or more cross-domain clusters or the identifier of the resource pool where the clusters are located. The second information indicates the permission operation type for the one or more cross-domain clusters.

[0044] Based on the first information and the second information, a third information is determined, wherein the third information represents the relevant information and / or relevant parameters of the first interface corresponding to the first request in the set components of the one or more cross-domain clusters;

[0045] Based on the third information, the first interface of the setting component of the one or more cross-domain clusters is invoked to perform the setting operation corresponding to the first request on the one or more cross-domain clusters.

[0046] Here, the first request includes at least first information and second information; upon receiving the first request, the first information and second information are obtained from the first request; upon obtaining the first information and second information, third information is determined based on the first information and second information, thereby enabling the first interface of one or more cross-domain cluster configuration components to be found and invoked based on the third information.

[0047] When the first request is used to request permission to view one or more cross-domain clusters, the third information represents the relevant information of the first interface corresponding to the first request in the configuration components of one or more cross-domain clusters, or the relevant information and parameters of the first interface corresponding to the first request in the configuration components of one or more cross-domain clusters. When the first request is used to request permission management for one or more cross-domain clusters, the third information represents the relevant information and parameters of the first interface corresponding to the first request in the configuration components of one or more cross-domain clusters.

[0048] It's important to note that a cluster identifier uniquely identifies the cluster; it can be the cluster name or ID. Similarly, a resource pool identifier uniquely identifies the resource pool; it can be the resource pool name or ID. Cluster permission operations can target different objects, including services, policies, and users. Permission operation types for different objects can include view, create, modify, and delete; for example, view services, view policies, and view users. A service can refer to the services and / or resources that the cluster can provide. Policies can include read, write, and access. Users can be represented by username, user ID, and user identity. Permissions can also be understood as permission policies or permission information, indicating whether a user is allowed or prohibited from reading, writing, or having access to a specific service. The interfaces on the cluster's configuration components can be understood as the native interfaces of the ranger admin deployed on that cluster—the interfaces called when managing permissions for a single cluster. Each interface corresponds one-to-one with the cluster's permission operation type. A configuration component can have one or more interfaces; for example, if the cluster's permission operation type is view services, the corresponding interface on the configuration component is the view services interface.

[0049] In order to accurately locate the first interface of one or more cross-domain cluster configuration components corresponding to the first request, in one embodiment, determining the third information based on the first information and the second information includes:

[0050] Based on the first information, a fourth piece of information is determined, which includes the deployment node, access port, and version number of the configuration component of the one or more cross-domain clusters.

[0051] The third information is determined based on the second information and the fourth information.

[0052] Here, with the first information representing the identifier of one or more cross-domain clusters, the one or more cross-domain clusters corresponding to the first request are determined based on the first information, thereby determining the deployment node, access port, and version number of the one or more cross-domain clusters, i.e., determining the fourth information. The third information is determined based on the second and fourth information; for example, the third information is determined based on the second information and the version number of the configuration components of one or more cross-domain clusters. The first node can obtain and store information such as the deployment node, access port, and version number from the configuration components of each cluster, or it can obtain and store information such as the deployment node, access port, and version number by receiving information reported by the configuration components of each cluster.

[0053] To accurately determine the first interface corresponding to the first request in one or more cross-domain cluster configuration components, in one embodiment, determining the third information based on the second information and the fourth information includes:

[0054] Based on the second information and the version number of the configuration component of the one or more cross-domain clusters, fifth information is determined, wherein the fifth information represents the relevant information of the first interface corresponding to the first request in the configuration component of the one or more cross-domain clusters.

[0055] Here, the information related to the interface of the cluster configuration component corresponds to the permission operation type and the version number of the configuration component. Therefore, based on the second information and the version numbers of one or more cross-domain cluster configuration components, the information related to the first interface of the one or more cross-domain cluster configuration components can be determined. The first interface of one or more cross-domain cluster configuration components can represent the interface corresponding to the first request in the one or more cross-domain cluster configuration components.

[0056] After determining the fifth piece of information, if the setting operation corresponding to the first request is "view," the first interface of one or more cross-domain cluster setting components can be directly called based on the fifth piece of information to obtain relevant permission information from the second nodes of one or more cross-domain clusters. This permission information can then be displayed on the page for administrator viewing. The second node is the node where the cluster setting component resides. If the setting operation corresponding to the first request is "delete," the first interface of one or more cross-domain cluster setting components can also be called based on the fifth piece of information to delete the relevant permission information from the second nodes of one or more cross-domain clusters. The deleted permission information can also be obtained from the second nodes of one or more cross-domain clusters and displayed on the page for administrator viewing. If the setting operation corresponding to the first request is "create," the creation permission information entered by the administrator can be obtained first, and then the first interface of one or more cross-domain cluster setting components can be called based on the fifth piece of information to create and store the relevant permission information in the second nodes of one or more cross-domain clusters. If the setting operation corresponding to the first request is "modify," the first interface can be called directly, or the information entered by the administrator can be obtained first, and then the first interface of one or more cross-domain cluster setting components can be called to modify the relevant permission information in the second nodes of one or more cross-domain clusters.

[0057] To facilitate and accurately invoke the first interface, in one embodiment, the relevant information of the first interface includes the following items:

[0058] The call path of the first interface;

[0059] The calling method of the first interface;

[0060] Manage and / or view the parameter list corresponding to the operation;

[0061] Manage and / or view the list of parameter types corresponding to the operation.

[0062] Here, when the setting operation corresponding to the first request is to view or delete, the relevant information of the first interface may include the call path and call method of the first interface, that is, directly obtaining or deleting all permission information of the setting component management of one or more cross-domain clusters; in this case, the relevant information of the first interface may also include the parameter list and parameter type list corresponding to the management and / or view operation, that is, based on the parameter list and parameter type list, obtaining or deleting the permission information of the setting component management of one or more cross-domain clusters. When the setting operation corresponding to the first request is to create or modify, the relevant information of the first interface may include the call path and call method of the first interface, as well as the parameter list and parameter type list corresponding to the management and / or view operation. The first interface call path is used to call the first interface based on the call path under the configuration component of one or more cross-domain clusters; the call methods of the first interface include GET (view), POST (create or modify), PUT (modify), and DELETE (delete); manage and / or view the parameter list and parameter type list corresponding to the operation, which are used to render the second user interface. The parameter type list may include one or more of the following parameter types: string, integer, long integer, single-precision floating-point, double-precision floating-point, file, date, and boolean.

[0063] In order to dynamically generate a visual page and obtain administrator input parameters, in one embodiment, a second user interface is rendered based on the first request and the fifth information;

[0064] Obtain the information input through the second user interface to get the relevant parameters of the first interface corresponding to the first request in the configuration components of the one or more cross-domain clusters.

[0065] Here, after determining the fifth piece of information and the setting operation corresponding to the first request is creation or modification, based on the setting operation (creation or modification) corresponding to the first request, the user interface to be displayed (creation interface or modification interface) is determined. Based on the parameter list and parameter type list corresponding to the management and / or viewing operations included in the fifth piece of information, the input fields are rendered to generate the second user interface. The information input on the second user interface can be obtained through the second request, which can be triggered on the second user interface, thereby obtaining the relevant parameters of the first interface of the setting component of one or more cross-domain clusters, i.e., determining the third piece of information. Based on the third piece of information, the first interface of the setting component of one or more cross-domain clusters is called to perform the setting operation (creation or modification) corresponding to the first request on one or more cross-domain clusters.

[0066] It should be noted that, if the setting operation corresponding to the first request is to view or delete, the first interface of one or more cross-domain cluster setting components can be directly called to obtain relevant permission information and generate a third user interface; or, based on the parameter list and parameter type list corresponding to the management and / or viewing operations included in the fifth information, the first interface of one or more cross-domain cluster setting components can be called to obtain the data corresponding to the parameter list and generate a third user interface.

[0067] In this embodiment, a visual interface can be dynamically generated based on the first request and the fifth information to achieve a unified view of dynamic visualization. The cross-domain multi-cluster unified permission management visualization method based on the dynamic visualization mechanism can improve the flexibility and operability of cluster permission operation and maintenance, and reduce operation and maintenance costs and complexity.

[0068] In order to determine the fourth information and achieve unified access control across multiple domains and clusters, in one embodiment, determining the fourth information based on the first information includes:

[0069] The fourth information is determined based on the first information and the first relationship, wherein the first relationship includes one or more of the following:

[0070] The correspondence between the cluster and the second node, access port, and version number; the second node is used to deploy and configure components.

[0071] The correspondence between resource pools and clusters.

[0072] Here, the first relationship can include the correspondence between the cluster and the second node, the access port, and the version number. For example, the first relationship can include the correspondence between the cluster identifier and the second node, the access port, and the version number. The cluster identifier can be the name of the cluster. Considering that unified permission management can also be performed on clusters under the resource pool, the first information can represent the identifier of the resource pool. The first relationship can also include the correspondence between the resource pool and the cluster. The first relationship can be stored in the storage module of the first node.

[0073] When the first information represents the identifier of one or more cross-domain clusters, the second node, access port, and version number corresponding to the first information can be directly found in the first relationship to determine the fourth information. When the first information represents the identifier of a resource pool, based on the first information and the correspondence between resource pools and clusters in the first relationship, all clusters under the resource pool corresponding to the first information are found. Then, based on the found all clusters under the resource pool corresponding to the first information, and the correspondence between clusters and second nodes, access ports, and version numbers in the first relationship, the second node, access port, and version number corresponding to all clusters under the resource pool corresponding to the first information are found to determine the fourth information.

[0074] For example, the first relationship can be stored in the database in the form of data tables, which can include: a first data table, a second data table, and a third data table. For instance, in the first data table shown in Table 1, each record corresponds to a primary key. The primary key is used to uniquely identify each record in the table; that is, a primary key in the first data table corresponds to the deployment address of a second node in a cluster, the access port of the configuration component on the second node, and the version number. The fields in the first data table include the primary key, the second node, the access port, and the version number. For example, the primary key corresponding to the first record in Table 1 is A_1, and the first record includes the deployment address of the second node (10.172.162.19), the access port of the configuration component on the second node (6080), and the version number (0.5.3). The first data table can be understood as a ranger deployment information table, which can be obtained by storing the sixth information reported by the second nodes of different clusters.

[0075] Table 1 First Data Table

[0076] In the second data table shown in Table 2, each record also corresponds to a primary key. The primary key is used to uniquely identify each record in the table, that is, one primary key in the second data table corresponds to one resource pool and one cluster. The fields in the second data table include the primary key, resource pool name, and cluster name. For example, the primary key corresponding to the first record in Table 2 is B_1, and the first record includes the correspondence between the Suzhou resource pool and the Suzhou Hadoop cluster. The second data table can be understood as a virtual hierarchical table, used to maintain the hierarchical relationship between resource pools and clusters, to identify information about each cluster, and to represent the resource pool information of each cluster.

[0077] Table 2 Second Data Table

[0078] In the third data table shown in Table 3, each record also corresponds to a primary key. The primary key is used to uniquely identify each record in the table; that is, one primary key in the third data table corresponds to a primary key in the first data table and a primary key in the second data table. The fields in the third data table include the primary key, the primary key of the second data table, and the primary key of the first data table. For example, the primary key corresponding to the first record in Table 3 is C_1, and the first record includes the correspondence between the primary key A_1 of the first data table and the primary key B_1 of the second data table. The third data table can be understood as a ranger and hierarchical association table, used to associate the first data table and the second data table, representing the ranger permission management address corresponding to each cluster.

[0079] Table 3 Third Data Table

[0080] The process of determining the fourth information based on the first information and the first relationship represented by the three data tables mentioned above is shown in Figure 4. The primary keys of one or more second data tables corresponding to the first information can be determined from the second data tables based on the first information. For example, if the first information represents the name of one or more cross-domain clusters, the primary keys of one or more records corresponding to the names of these cross-domain clusters can be determined from the second data tables. If the first information represents the name of a resource pool, the names of one or more cross-domain clusters corresponding to the name of the resource pool can be determined from the second data tables. Then, based on the names of these cross-domain clusters, the primary keys of one or more records corresponding to the names of these cross-domain clusters can be determined from the second data tables. Then, based on the primary keys of one or more second data tables corresponding to the first information, the primary keys of one or more first data tables corresponding to the primary keys of these one or more second data tables can be determined from the third data tables. Finally, based on the primary keys of one or more first data tables, one or more records corresponding to the primary keys of these one or more first data tables can be determined from the first data tables, thus determining the fourth information.

[0081] To improve the scalability and fault tolerance of unified permission management for big data components across multiple domains and clusters, in one embodiment, the method further includes:

[0082] Receive sixth information reported by one or more second nodes, including the access port and version number of the configuration components deployed on the second node;

[0083] The first relationship is established based on the received sixth information, or the first relationship is established based on the received sixth information and the resource pool where the cluster is located.

[0084] Here, receiving the sixth information reported by one or more second nodes can be receiving the sixth information reported by the reporting modules of one or more second nodes; for example, as shown in Figure 5, the first node receives the sixth information reported by the reporting modules of the second nodes of cluster 1, cluster 2, and cluster 3; based on the received sixth information reported by the second nodes of each cluster, a correspondence between each cluster and the sixth information is established, i.e., a first relationship is established; or, based on the received sixth information of each cluster and the resource pool where each cluster is located, a correspondence between each cluster and the sixth information, as well as a correspondence between each cluster and the resource pool, is established, thereby establishing a first relationship; the established first relationship is stored in the storage module.

[0085] To achieve unified permission management based on the permission management framework of each cluster, thereby improving the scalability and fault tolerance of unified permission management for big data components across multiple domains and clusters, and reducing operation and maintenance costs and difficulties, in one embodiment, the determination of the fifth information based on the second information and the version number of the set component of the one or more cross-domain clusters includes:

[0086] Based on the second information and the version numbers of the configuration components of the one or more cross-domain clusters, and the second relationship, the fifth information is determined; the second relationship includes:

[0087] The interface information, version number, and the correspondence between the component's interface and its associated information; or

[0088] The correspondence between version numbers and the interfaces of the configured components, and the correspondence between the interfaces of the configured components and their related information.

[0089] Here, when the second relationship includes the correspondence between interface-related information and version numbers, and the interface of the configuration component, the fifth information can be directly retrieved from the second relationship based on the version numbers included in the second and fourth information. When the second relationship includes the correspondence between version numbers and the interface of the configuration component, and the correspondence between the interface of the configuration component and its related information, the first interface corresponding to the permission operation type indicated by the second information in the configuration component corresponding to the version number can be determined based on the version numbers of the configuration components of one or more cross-domain clusters, and the correspondence between version numbers and the interface of the configuration component in the second relationship. This process can be understood as determining the first interface corresponding to the second information from the interfaces of the configuration component under the permission management framework version corresponding to the version number of the configuration component in the cluster; based on the determined first interface and the correspondence between the interface of the configuration component and its related information in the second relationship, the related information of the first interface is determined, i.e., the fifth information is determined. The interface of the configuration component can be represented by an interface code or an interface name. The correspondence between version numbers and the interface of the configuration component can be understood as a hierarchical relationship between version numbers and the interface of the configuration component.

[0090] For example, in one or more cross-domain clusters, there exists a cluster whose configuration component is version v1. The second information obtained by the first node from the first request indicates that the permission operation type of this cluster is creation policy. Based on the second information, the version number of the configuration component of this cluster, and the second relationship, the fifth information determines that the call path of the first interface is " / ranger / api / v1 / createpolicy", the call method of the first interface is "post", the parameter list corresponding to the creation operation includes user identifier (userId), service identifier (serviceId), policy identifier (policyId), and policy name (policyName), and the parameter type list corresponding to the creation operation includes string, string, string, string.

[0091] It should be noted that when the interface of a setting component is represented by an interface code, one interface code indicates one type of permission operation. The interface codes for the same permission operation type corresponding to different version numbers can be the same or different. When the interface codes for the same permission operation type corresponding to different version numbers are the same, the second relationship can include the correspondence between the interface's relevant information and the version number and interface code. For example, as shown in Figure 6, the objects targeted by the interface of a setting component corresponding to a version number include services, policies, and users. The permission operation types corresponding to each object include create, modify, delete, and view. That is, the interface of the setting component corresponding to each object includes a create interface, a modify interface, a delete interface, and a view interface. An interface code is generated for each of these permission operation types; for example, the interface code for the create policy interface for a policy is create_policy.

[0092] When different version numbers correspond to different interface codes for the same permission operation type, that is, when each interface code can uniquely correspond to a version number and a permission operation type, the second relationship can include: the correspondence between the interface code and the relevant information of the interface.

[0093] In order to collect relevant information about the native interfaces of the configuration components in various versions, and to call the underlying native interfaces to achieve unified management of cluster permissions, thereby reducing operation and maintenance costs and difficulties, in one embodiment, the method further includes:

[0094] Receive the ninth information reported by the second node of each version. The ninth information includes information about the interface of the configuration component deployed by the second node of each version, or the correspondence between the interface of the configuration component deployed by the second node of each version and the relevant information of the interface.

[0095] The second relationship is established based on the received ninth information.

[0096] Here, the ninth information reported by the second node of each version can be the ninth information reported by the instrumentation module of the second node of each cluster. The instrumentation module is used to intercept interface call requests and obtain interface-related information of the set components. The instrumentation module is deployed in the second node of each version.

[0097] If the ninth information includes information about the interfaces of the configuration components deployed on the second node for each version, the version number can be determined based on the interface call path in the interface information, and the permission operation type can be determined based on the interface call method in the interface information. Therefore, a second relationship can be established based on the determined version number, permission operation type, and the received ninth information. If the ninth information includes the correspondence between the interfaces of the configuration components deployed on the second node for each version and the related information of those interfaces, a second relationship can be established directly based on the received ninth information.

[0098] It should be noted that before receiving the ninth information reported by the second node of each version, the native interfaces of the setting components of each version can be organized and stored separately; for example, the native interfaces of the setting components of each version can be packaged and stored.

[0099] In this embodiment, the process of receiving the ninth information reported by the second nodes of each version and establishing a second relationship based on the received ninth information can be understood as the collection process or collection mechanism of the native interfaces of the setting components of each version. Based on the second relationship, differentiated calls to the interfaces of the setting components of clusters using different permission management framework versions can be realized. The collection process of the native interfaces of the setting components of different versions can be triggered simultaneously or separately for each version.

[0100] The following section provides a more detailed description of this application with reference to application examples.

[0101] It should be noted that before performing cluster permission management, a first relationship and a second relationship need to be established in advance. Taking triggering an interface call in the setting component of version 0.5.3 as an example, the specific method for establishing the second relationship is shown in Figure 7. In Figure 7, the event tracking module is deployed on the second node in the cluster using the permission management framework of version 0.5.3, while the management module and storage module are deployed on the first node. The specific steps for establishing the second relationship include:

[0102] Step 1: The administrator triggers the API call in the permission management interface corresponding to each version.

[0103] Here, the administrator triggers interface calls on the permission management interface corresponding to each version, including triggering interface calls for different objects (such as services, policies, and users); the permission management interface corresponding to each version is the original ranger web page, that is, the interface for managing permissions for a single cluster; for example, clicking "Create Policy" on the permission management interface.

[0104] Step 2: The second node's event tracking module intercepts interface call requests.

[0105] Here, the administrator triggers an API call on the permission management interface, generating an API call request that is sent to the designated component on the second node. The event tracking module deployed on the second node intercepts the API call request sent to the designated component and parses the relevant information of the corresponding API from the request. This information includes the API call path and method, and / or the parameter list and parameter type list corresponding to the operation performed by the API. The event tracking module is an interception filter implemented by modifying the ranger source code, used to intercept API call requests sent to the designated component on the second node and obtain the relevant API information.

[0106] Step 3: The event tracking module of the second node sends an interface trigger message to the management module of the first node.

[0107] Here, the second node's event tracking module sends an interface trigger message to the first node's management module to obtain the interface code or transmit relevant interface information to the first node; that is, the interface trigger message may include relevant interface information (ninth information) parsed by the second node's event tracking module, or at least include the permission operation or permission operation type corresponding to the interface call request.

[0108] If the interface trigger message includes relevant information about the interface parsed by the second node's tracking module (the ninth information), proceed to step 5; if the interface trigger message includes at least the permission operation or permission operation type corresponding to the interface call request, proceed to step 4.

[0109] Step 4: The management module of the first node returns the interface code corresponding to the interface call request.

[0110] Here, the management module of the first node determines the interface code corresponding to the received interface trigger message, i.e., the interface code corresponding to the interface call request, and returns the interface code corresponding to the interface call request to the instrumentation module of the second node. For example, if the interface call request is used to call the creation policy interface, the interface code corresponding to the interface call request determined by the management module of the first node is create_policy. The instrumentation module of the second node matches the received interface code with the relevant information of the interface parsed from the interface call request to obtain the correspondence between the interface code and the relevant information of the interface; and sends the correspondence between the interface code and the relevant information of the interface (the ninth information) to the storage module of the first node.

[0111] Step 5: The first node receives the ninth message.

[0112] Here, when the ninth information is related to the interface, the first node determines the version number and the interface corresponding to the interface call request based on the relevant information of the interface. Based on the relevant information of the interface, the version number and the interface corresponding to the interface call request, a second relationship is established and stored in the storage module. When the ninth information is the correspondence between the interface code and the relevant information of the interface, the ninth information is directly stored in the storage module.

[0113] The first node can establish the second relationship of each interface for each version based on the steps of establishing a second relationship of an interface in Figure 7.

[0114] As shown in Figure 8, taking the creation of policies under resource pool A and resource pool B as an example, the cluster permission management method includes the following steps:

[0115] Step 801: The administrator clicks "Create Policy" in the first user interface.

[0116] Here, the administrator can select resource pool A and resource pool B in the first user interface and then click the "Create Policy" button to generate a first request. The first user interface is a unified permission management interface for one or more cross-domain clusters or resource pools. The first request is used to request permission management and / or viewing for all clusters under resource pool A and resource pool B. The first request includes at least first information and second information. The first information represents the identifiers of resource pool A and resource pool B, and the second information indicates that the permission operation type for all clusters under resource pool A and resource pool B is to create a policy (i.e., the permission operation is against a policy, and the operation performed is creation).

[0117] Step 802: The first node receives the first request and obtains the first information and the second information from the first request.

[0118] For details on the implementation of step 802, please refer to the relevant description above; it will not be repeated here.

[0119] Step 803: The first node determines the fourth information based on the first information and the first relationship.

[0120] Here, the first relationship can be stored in the database in the form of data tables, such as the first data table, second data table, and third data table mentioned above. The first node can query the data tables in the first relationship sequentially based on the first information to determine the fourth information. For example, as shown in Figure 9, the management module of the first node obtains the first information, queries the second data table based on the first information, and obtains the primary key of the second data table corresponding to the records of all clusters under resource pool A and resource pool B. The clusters under resource pool A include cluster 1, cluster 2, and cluster 3, and the clusters under resource pool B include cluster 4 and cluster 5. Based on the primary key of the second data table, it queries the third data table to obtain the primary key of the first data table corresponding to the primary key of the second data table. Based on the primary key of the first data table, it queries the first data table to obtain the fourth information, which includes the deployment node, access port, and version number of the configuration component for all clusters under resource pool A and resource pool B.

[0121] Step 804: The first node determines the fifth information based on the second information, the version number of one or more cross-domain cluster configuration components, and the second relationship.

[0122] For details on the implementation of step 804, please refer to the relevant description above; it will not be repeated here.

[0123] Step 805: The first node renders the second user interface based on the first request and the fifth information.

[0124] Here, the first node renders the second user interface based on the first request and the fifth information. For example, the first node determines the specific function type of the second user interface (such as the policy creation function) based on the first request, and renders the second user interface based on the parameter list and parameter type list corresponding to the management and / or viewing operations in the fifth information. For example, the parameter list includes service name (serviceName), user name (userName), policy name (policyName), and whether to authorize (isPublish). The parameter type list includes string (String), string, string, string or integer (int), and boolean. The second user interface is shown in Figure 10.

[0125] Step 806: The administrator enters information in the second user interface.

[0126] Here, the administrator can enter the relevant information for creating the policy in the second user interface, create user permissions (including allow or deny) for reading, writing or accessing the service, and click the "Save" button.

[0127] Step 807: The first node obtains the information input through the second user interface and gets the relevant parameters of the first interface corresponding to the first request in one or more cross-domain cluster configuration components.

[0128] Here, when the administrator clicks the "Save" button, the information entered by the administrator can be transmitted to the first node, so that the first node can obtain the relevant parameters of the first interface corresponding to the first request in one or more cross-domain cluster configuration components, determine the third information, and then call the first interface of one or more cross-domain cluster configuration components based on the third information to complete the permission management operation corresponding to the first request.

[0129] Step 808: Based on the fourth and third information, the first node calls the first interface of the setting component of one or more cross-domain clusters to perform the setting operation corresponding to the first request on one or more cross-domain clusters.

[0130] Here, the first node can obtain the access path of the first interface of the configuration component of one or more cross-domain clusters based on the fourth and third information. Based on the information entered by the administrator in the second user interface, it generates a creation policy request and calls the first interface under the access path of the first interface of the configuration component in each of the one or more cross-domain clusters. It then initiates the same creation policy request for each configuration component in each cluster, completing the unified creation or addition of permission policies. For example, the "Save" button can link to "http: / / rangerIp:rangerPort / rangerApi" to call the first interface of one or more cross-domain cluster configuration components; where rangerIp represents the address of the second node, rangerPort represents the access port of the configuration component of the second node, and rangerApi represents the call path of the first interface (e.g., / ranger / api / v1 / createpolicy). For example, the first node can form the access path of the first interface of the configuration component of all clusters under resource pool A and resource pool B based on the fourth and third information. When rendering the second user interface based on the first request and the fifth information, the "Save" button is linked to the access path of the first interface of the configuration component of all clusters under resource pool A and resource pool B. The administrator enters information on the second user interface and clicks the "Save" button. Based on the information entered by the administrator, the first node generates a creation policy request, calls the first interface under the access path of the first interface of the configuration component of each cluster under resource pool A and resource pool B, and initiates the same creation policy request for the configuration component of each cluster, thus completing the unified creation or addition of permission policies.

[0131] To implement the method on the first node side of this application embodiment, this application embodiment also provides a cluster permission management device, which is installed on the first node, as shown in FIG11. The device includes:

[0132] The first receiving unit 1101 is configured to receive a first request, which is triggered by the first user interface of the first node and is used to request the management and / or viewing of permissions for one or more cross-domain clusters.

[0133] Calling unit 1102 is configured to execute the setting operation corresponding to the first request on each cluster corresponding to the first request by calling the setting component of each cluster corresponding to the first request.

[0134] In one embodiment, the calling unit 1102 is further configured to obtain first information and second information from the first request, wherein the first information represents the identifier of the one or more cross-domain clusters or the identifier of the resource pool in which the clusters reside, and the second information indicates the permission operation type for the one or more cross-domain clusters.

[0135] Based on the first information and the second information, a third information is determined, wherein the third information represents the relevant information and / or relevant parameters of the first interface corresponding to the first request in the set components of the one or more cross-domain clusters;

[0136] Based on the third information, the first interface of the setting component of the one or more cross-domain clusters is invoked to perform the setting operation corresponding to the first request on the one or more cross-domain clusters.

[0137] In one embodiment, the calling unit 1102 is further configured to determine fourth information based on the first information, the fourth information including the deployment node, access port and version number of the setting component of the one or more cross-domain clusters; and to determine the third information based on the second information and the fourth information.

[0138] In one embodiment, the calling unit 1102 is further configured to determine fifth information based on the second information and the version number of the setting component of the one or more cross-domain clusters, wherein the fifth information represents the relevant information of the first interface corresponding to the first request in the setting component of the one or more cross-domain clusters.

[0139] In one embodiment, the device further includes:

[0140] The rendering unit is configured to render a second user interface based on the first request and the fifth information;

[0141] The acquisition unit is configured to acquire information input through the second user interface to obtain relevant parameters of the first interface corresponding to the first request in the configuration components of one or more cross-domain clusters.

[0142] In one embodiment, the calling unit 1102 is further configured to determine the fourth information based on the first information and the first relationship, wherein the first relationship includes one or more of the following:

[0143] The correspondence between the cluster and the second node, access port, and version number; the second node is used to deploy and configure components.

[0144] The correspondence between resource pools and clusters.

[0145] In one embodiment, the device further includes:

[0146] The second receiving unit is configured to receive sixth information reported by one or more second nodes. The sixth information includes the access port and version number of the configuration component deployed on the second node.

[0147] The first establishing unit is configured to establish the first relationship based on the received sixth information, or to establish the first relationship based on the received sixth information and the resource pool where the cluster is located.

[0148] In one embodiment, the relevant information of the first interface includes the following:

[0149] The call path of the first interface;

[0150] The calling method of the first interface;

[0151] Manage and / or view the parameter list corresponding to the operation;

[0152] Manage and / or view the list of parameter types corresponding to the operation.

[0153] In one embodiment, the calling unit 1102 is further configured to determine fifth information based on the second information, the version number of the set component of the one or more cross-domain clusters, and the second relationship; the second relationship includes:

[0154] The interface information, version number, and the correspondence between the component's interface and its associated information; or

[0155] The correspondence between version numbers and the interfaces of the configured components, and the correspondence between the interfaces of the configured components and their related information.

[0156] In one embodiment, the device further includes:

[0157] The third receiving unit is configured to receive the ninth information reported by the second node of each version. The ninth information includes the relevant information of the interface of the setting component deployed by the second node of each version, or the correspondence between the interface of the setting component deployed by the second node of each version and the relevant information of the interface.

[0158] The second establishing unit is configured to establish the second relationship based on the received ninth information.

[0159] In practical applications, the first receiving unit 1101, the second receiving unit, and the third receiving unit can be implemented by the processor in the cluster permission management device in conjunction with the communication interface; the calling unit 1102, the rendering unit, the acquisition unit, the first establishing unit, and the second establishing unit can be implemented by the processor in the cluster permission management device.

[0160] It should be noted that the above embodiments of the cluster permission management device are only illustrative examples of the division of program modules. In practical applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the device can be divided into different program modules to complete all or part of the processing described above. Furthermore, the cluster permission management device and the cluster permission management method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0161] Based on the hardware implementation of the above program modules, and in order to implement the method on the first node side of the embodiments of this application, the embodiments of this application also provide a first node, as shown in FIG12, the first node 1200 includes:

[0162] The communication interface 1201 allows for information exchange with other network nodes.

[0163] The processor 1202 is connected to the communication interface 1201 to enable information interaction with other network nodes and to execute the methods provided by one or more technical solutions on the first node side when running a computer program.

[0164] The memory 1203 is used to store computer programs that can run on the processor 1202.

[0165] Specifically, the communication interface 1201 is configured to receive a first request, which is triggered by the first user interface of the first node, for requesting permission management and / or viewing of one or more cross-domain clusters;

[0166] The processor 1202 is configured to execute the setting operation corresponding to the first request on each cluster corresponding to the first request by calling the setting component of each cluster corresponding to the first request.

[0167] In one embodiment, the processor 1202 is further configured to obtain first information and second information from the first request, wherein the first information represents the identifier of the one or more cross-domain clusters or the identifier of the resource pool in which the clusters reside, and the second information indicates the permission operation type for the one or more cross-domain clusters.

[0168] Based on the first information and the second information, a third information is determined, wherein the third information represents the relevant information and / or relevant parameters of the first interface corresponding to the first request in the set components of the one or more cross-domain clusters;

[0169] Based on the third information, the first interface of the setting component of the one or more cross-domain clusters is invoked to perform the setting operation corresponding to the first request on the one or more cross-domain clusters.

[0170] In one embodiment, the processor 1202 is further configured to determine fourth information based on the first information, the fourth information including the deployment node, access port, and version number of the configuration component of the one or more cross-domain clusters; and to determine third information based on the second information and the fourth information.

[0171] In one embodiment, the processor 1202 is further configured to determine fifth information based on the second information and the version number of the configuration component of the one or more cross-domain clusters, the fifth information representing the relevant information of the first interface corresponding to the first request in the configuration component of the one or more cross-domain clusters.

[0172] In one embodiment, the processor 1202 is further configured to render a second user interface based on the first request and the fifth information; obtain information input through the second user interface to obtain relevant parameters of the first interface corresponding to the first request in the set components of one or more cross-domain clusters.

[0173] In one embodiment, the processor 1202 is further configured to determine the fourth information based on the first information and the first relationship, wherein the first relationship includes one or more of the following:

[0174] The correspondence between the cluster and the second node, access port, and version number; the second node is used to deploy and configure components.

[0175] The correspondence between resource pools and clusters.

[0176] In one embodiment, the communication interface 1201 is further configured to receive sixth information reported by one or more second nodes, the sixth information including the access port and version number of the configuration component deployed by the second node;

[0177] The processor 1202 is further configured to establish the first relationship based on the received sixth information, or to establish the first relationship based on the received sixth information and the resource pool where the cluster is located.

[0178] In one embodiment, the relevant information of the first interface includes the following:

[0179] The call path of the first interface;

[0180] The calling method of the first interface;

[0181] Manage and / or view the parameter list corresponding to the operation;

[0182] Manage and / or view the list of parameter types corresponding to the operation.

[0183] In one embodiment, the processor 1202 is further configured to determine fifth information based on the second information, the version numbers of the designated components of the one or more cross-domain clusters, and a second relationship; the second relationship includes:

[0184] The interface information, version number, and the correspondence between the component's interface and its associated information; or

[0185] The correspondence between version numbers and the interfaces of the configured components, and the correspondence between the interfaces of the configured components and their related information.

[0186] In one embodiment, the communication interface 1201 is further configured to receive ninth information reported by each version of the second node. The ninth information includes information related to the interface of the setting component deployed by each version of the second node, or the correspondence between the interface of the setting component deployed by each version of the second node and the relevant information of the interface.

[0187] The processor 1202 is further configured to establish the second relationship based on the received ninth information.

[0188] It should be noted that the specific processing procedures of processor 1202 and communication interface 1201 can be understood by referring to the above method.

[0189] Of course, in practical applications, the various components in the first node 1200 are coupled together through the bus system 1204. It can be understood that the bus system 1204 is configured to enable communication between these components. In addition to the data bus, the bus system 1204 also includes a power bus, a control bus, and a status signal bus. However, for clarity, all buses are labeled as bus system 1204 in Figure 12.

[0190] The memory 1203 in this embodiment is configured to store various types of data to support the operation of the first node 1200. Examples of such data include any computer program used to operate on the first node 1200.

[0191] The methods disclosed in the above embodiments of this application can be applied to the processor 1202, or implemented by the processor 1202. The processor 1202 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in the processor 1202 or by instructions in the form of software. The processor 1202 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor 1202 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly reflected as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in the memory 1203. The processor 1202 reads the information in the memory 1203 and completes the steps of the aforementioned method in conjunction with its hardware.

[0192] In an exemplary embodiment, the first node 1200 may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to perform the aforementioned method.

[0193] It is understood that the memory (memory 1203) in the embodiments of this application can be volatile memory or non-volatile memory, or it can include both volatile memory and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); the magnetic surface memory can be disk storage or magnetic tape storage. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memories described in the embodiments of this application are intended to include, but are not limited to, these and any other suitable types of memories.

[0194] In an exemplary embodiment, this application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a memory 1203 storing a computer program, which can be executed by the processor 1202 of the first node 1200 to complete the steps described in the aforementioned first node-side method. The computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM.

[0195] For example, embodiments of this application also provide a computer program product, including a computer program that can be executed by the processor 1202 of the first node 1200 to perform the steps described in any of the foregoing methods.

[0196] It should be noted that terms such as "first" and "second" are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence; "multiple" refers to two or more items. The term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, the technical solutions described in the embodiments of this application can be arbitrarily combined without conflict. The above descriptions are merely preferred embodiments of this application and are not intended to limit the scope of protection of this application.

Claims

1. A cluster permission management method, applied to a first node, the method comprising: Receive a first request, which is triggered in the first user interface of the first node, for requesting permission management and / or viewing of one or more cross-domain clusters; By invoking the configuration component of each cluster corresponding to the first request, the configuration operation corresponding to the first request is executed on each cluster corresponding to the first request.

2. The method according to claim 1, wherein, The step of executing the specified operation corresponding to the first request on each cluster by invoking the specified component corresponding to the first request includes: Obtain first information and second information from the first request. The first information represents the identifier of the one or more cross-domain clusters or the identifier of the resource pool where the clusters are located. The second information indicates the permission operation type for the one or more cross-domain clusters. Based on the first information and the second information, a third information is determined, wherein the third information represents the relevant information and / or relevant parameters of the first interface corresponding to the first request in the set components of the one or more cross-domain clusters; Based on the third information, the first interface of the setting component of the one or more cross-domain clusters is invoked to perform the setting operation corresponding to the first request on the one or more cross-domain clusters.

3. The method according to claim 2, wherein, The step of determining the third information based on the first information and the second information includes: Based on the first information, a fourth piece of information is determined, which includes the deployment node, access port, and version number of the configuration component of the one or more cross-domain clusters. The third information is determined based on the second information and the fourth information.

4. The method according to claim 3, wherein, Determining the third information based on the second information and the fourth information includes: Based on the second information and the version number of the configuration component of the one or more cross-domain clusters, fifth information is determined, wherein the fifth information represents the relevant information of the first interface corresponding to the first request in the configuration component of the one or more cross-domain clusters.

5. The method according to claim 4, wherein, The method further includes: A second user interface is rendered based on the first request and the fifth information; Obtain the information input through the second user interface to get the relevant parameters of the first interface corresponding to the first request in the configuration components of the one or more cross-domain clusters.

6. The method according to claim 3, wherein, The step of determining the fourth information based on the first information includes: The fourth information is determined based on the first information and the first relationship, wherein the first relationship includes one or more of the following: The correspondence between the cluster and the second node, access port, and version number; the second node is used to deploy and configure components. The correspondence between resource pools and clusters.

7. The method according to claim 4, wherein, The method further includes: Receive sixth information reported by one or more second nodes, including the access port and version number of the configuration components deployed on the second node; The first relationship is established based on the received sixth information, or the first relationship is established based on the received sixth information and the resource pool where the cluster is located.

8. The method according to any one of claims 2 to 6, wherein, The relevant information for the first interface includes the following items: The call path of the first interface; The calling method of the first interface; Manage and / or view the parameter list corresponding to the operation; Manage and / or view the list of parameter types corresponding to the operation.

9. The method according to claim 4, wherein, The fifth information, determined based on the second information and the version number of the configuration component of the one or more cross-domain clusters, includes: Based on the second information and the version numbers of the configuration components of the one or more cross-domain clusters, and the second relationship, the fifth information is determined; the second relationship includes: The interface information, version number, and the correspondence between the component's interface and its associated information; or The correspondence between version numbers and the interfaces of the configured components, and the correspondence between the interfaces of the configured components and their related information.

10. The method according to claim 9, wherein, The method further includes: Receive the ninth information reported by the second node of each version. The ninth information includes information about the interface of the configuration component deployed by the second node of each version, or the correspondence between the interface of the configuration component deployed by the second node of each version and the relevant information of the interface. The second relationship is established based on the received ninth information.

11. A cluster access control device, comprising: The first receiving unit is configured to receive a first request, which is triggered by the first user interface of the first node and is used to request the management and / or viewing of permissions for one or more cross-domain clusters. The calling unit is configured to execute the set operation corresponding to the first request on each cluster corresponding to the first request by calling the set component of each cluster corresponding to the first request.

12. A first node, comprising a processor and a memory configured to store a computer program capable of running on the processor. in, When the processor is configured to run the computer program, it performs the steps of the method according to any one of claims 1 to 10.

13. A storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 10.

14. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1 to 10.

Images