A dynamic permission Web terminal management method, device and medium for a multi-cluster environment

Abstract

The present invention discloses a method, device and medium for dynamic permission management of a multi-cluster environment. The method comprises: creating an isolated operation Pod in real time upon receiving a client request and generating a permission set including RBAC in the target cluster, injecting KubeConfig based on the ServiceAccount credential into the Pod so that the client can operate the cluster in a secure environment through WebSocket; and directly verifying the RBAC permission with the help of the Kubernetes native API Server to realize dynamic authentication. Through the dual cluster resource collaborative recovery mechanism, the management cluster Pod and the target cluster RBAC permission set are accurately deleted after the session ends, which completely solves the problems of rigid permission management, fragmented security policies and delayed resource recovery in traditional solutions, and significantly improves the security and resource utilization efficiency of terminal operations in a multi-cluster environment.

Description

Technical Field

[0001] The present application relates to the technical field of terminal security management based on Kubernetes, and in particular to a method, device, and medium for dynamic permission Web terminal management in a multi-cluster environment. Background Art

[0002] In a centralized multi-cluster management scenario based on Kubernetes, operations personnel need to remotely operate the target cluster through a web terminal. However, existing technologies have the following core issues:

[0003] Existing Web terminal systems are all directly connected to the target cluster's container, or directly use the system environment as a terminal, lacking environmental isolation and posing security risks.

[0004] Permission management relies on predefined Service Accounts and RBAC policies, requiring manual configuration of Roles / RoleBindings. This results in delayed permission adjustments and poor scalability, especially when adding new clusters or changing permissions, requiring repeated updates to cluster configurations. Permission policies are disconnected from external permission centers (such as enterprise IAM systems), making it impossible to dynamically synchronize user identities and permission scopes. This makes it difficult to correlate operation records with permission changes in real time during audits, leading to high compliance risks.

[0005] Therefore, in a centralized multi-cluster management scenario, how to achieve dynamic permission control and automated resource management has become a technical challenge that needs to be solved urgently. Summary of the Invention

[0006] The present application provides a method, device, and medium for dynamic permission management of a Web terminal in a multi-cluster environment to address at least one problem existing in the related art. The technical solution is as follows:

[0007] In a first aspect, an embodiment of the present application provides a method for managing dynamic permission web terminals in a multi-cluster environment, including:

[0008] Step 1: Receive a cluster session creation request from a client, the request including a target cluster identifier and a requested terminal type;

[0009] Step 2: Query the session registry to check whether there is a valid session for the user to connect to the target cluster; if there is a valid session, return the session identifier to the client; Step 2 is divided into the following steps:

[0010] Step 2-1: Use the user identity, target cluster ID, and cluster terminal type to query the session registry to see if there is an available session.

[0011] Step 2-2: If the session exists, the session identifier is returned to the client.

[0012] Step 3: If no valid session exists, create an isolated operation Pod in the management cluster and create a corresponding temporary RBAC permission set in the target cluster. At the same time, generate a unique session identifier to bind the Pod, and inject the KubeConfig information corresponding to the RBAC into the Pod. Step 3 is divided into the following steps:

[0013] Step 3-1: Create an operation Pod with security isolation properties in the management cluster;

[0014] Step 3-2: Generate a globally unique session identifier, bind it to the Pod, and register it in the session registry;

[0015] Step 3-3: Generate a cross-namespace RBAC permission set based on user permission data, which may include roles and role bindings for multiple target clusters;

[0016] Step 3-4: Generate the KubeConfig configuration corresponding to the RBAC permission set through the RBAC rendering module. The configuration contains the API Server endpoint, certificate authority data, and the Bearer Token obtained from the ServiceAccount.

[0017] Step 3-5: Create the RBAC permission set in the target cluster and inject the complete KubeConfig into the Pod environment;

[0018] The RBAC permission set includes: Role, RoleBinding, and ServiceAccount.

[0019] Step 4: Establish a connection between the client and the Pod through Websocket, so that the client can execute Shell instructions in the Pod and access the target cluster; Step 4 is divided into the following steps:

[0020] Step 4-1: The client sends a connection request carrying the session identifier via Websocket;

[0021] Step 4-2: The server is associated with the corresponding Pod according to the session identifier;

[0022] Step 4-3: Establish a Websocket bidirectional communication tunnel and forward the client input to the Shell environment of the Pod.

[0023] Step 5: When the client accesses the target cluster through the Pod, it is only allowed to access resources defined by the RBAC permission set. Step 5 is divided into the following steps:

[0024] Step 5-1: The client operates the Pod terminal to access resources on the target cluster;

[0025] Step 5-2: The access request passes through the API Server of the target cluster, obtains the Bearer Token and resolves the ServiceAccount. Based on the ServiceAccount and the corresponding RBAC permission set, it is determined whether the request has the right to access the corresponding resource; if the permission is granted, the request is allowed; if not, a prompt is displayed indicating insufficient access rights.

[0026] Step 6: After the client disconnects, if no further connection is requested, the server automatically reclaims the Pod resources and the temporary RBAC resources of the target cluster based on a timeout mechanism;

[0027] Step 6-1: Monitor the client connection status;

[0028] Step 6-2: If the connection is disconnected for more than the set time, the deletion process is triggered, and the session in the session registry, the Pod corresponding to the session identifier, and the temporary RBAC resources of the target cluster are deleted through the session identifier;

[0029] Step 6-3: Archive the Pod's operation log to persistent storage.

[0030] In a second aspect, an embodiment of the present application further provides a dynamic permission web terminal management system for a multi-cluster environment, including:

[0031] Session management module: executes step 1, generates a session identifier and creates an isolated operating environment Pod;

[0032] Communication proxy module: executes step 2 to establish a Websocket connection between the client and the Pod;

[0033] Permission verification module: executes step 3 and manages the user's permission to access cluster resources through the authentication module.

[0034] In a third aspect, embodiments of the present application further provide an electronic device comprising a memory and a processor. The memory stores instructions, which are loaded and executed by the processor to implement the steps of the above method. The memory and the processor communicate with each other via an internal connection path.

[0035] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, which implements the steps of the above method when executed by a processor.

[0036] The advantages or beneficial effects of the above technical solution include at least:

[0037] This application uses a dynamic access token and authentication module linkage mechanism to improve the efficiency of permission synchronization (from the traditional hours to seconds), reducing the operation and maintenance costs of manual configuration of Role / RoleBinding;

[0038] This project adopts a two-layer isolation architecture: network + environment. By limiting the Pod network access scope and minimizing the Shell environment, it improves the defense capability against container escape attacks and reduces the risk of illegal access to cluster resources.

[0039] This project takes into account the efficient recovery mechanism of session resources. By terminating Pods by timeout and archiving operation logs, it improves cluster resource utilization and reduces cost waste caused by idle resources.

[0040] The above summary is for illustrative purposes only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments and features described above, further aspects, embodiments and features of the present application will be readily apparent by reference to the accompanying drawings and the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. In the accompanying drawings, unless otherwise specified, the same reference numerals throughout multiple drawings represent the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that the following drawings only illustrate certain embodiments of the present application and should not be regarded as limiting the scope. For those of ordinary skill in the art, other relevant drawings can also be obtained based on these drawings without paying creative work.

[0042] Figure 1 This is a basic flow chart of an embodiment of the present application;

[0043] Figure 2 A schematic diagram of the system architecture of an embodiment of the present application;

[0044] Figure 3 A schematic diagram of a session creation process according to an embodiment of the present application;

[0045] Figure 4 This is a schematic diagram of the client connection process according to an embodiment of the present application;

[0046] Figure 5 This is a schematic diagram of the terminal operation process according to an embodiment of the present application. DETAILED DESCRIPTION

[0047] Hereinafter, only certain exemplary embodiments are briefly described. As will be appreciated by those skilled in the art, the described embodiments may be modified in various ways without departing from the spirit or scope of the present application. Therefore, the drawings and description are to be regarded as illustrative in nature and not restrictive.

[0048] In the first aspect, the present application discloses a method for managing dynamic permission Web terminals in a multi-cluster environment. The method flow chart is as follows: Figure 1 As shown, the following steps are included:

[0049] Please refer to Figure 2 , Figure 2 An exemplary schematic diagram of the architecture of a dynamic permission Web terminal management method in a multi-cluster environment of an example of the present disclosure is shown, which consists of a client, a central cluster including a server, and at least one target cluster.

[0050] Among them, the central cluster can be the core part of the cloud computing system, mainly responsible for the management of global resources and the management of other edge clusters, providing channels for users to uniformly manage edge clusters, that is, the target cluster in the figure.

[0051] Please refer to Figure 3 , Figure 3 A logical flow chart of creating a session in a dynamic permission Web terminal management method in a multi-cluster environment according to an example of the present disclosure is shown.

[0052] Step 1: Receive a cluster session creation request from a client, the request including a target cluster identifier and a requested terminal type;

[0053] Step 2: Query the session registry to check whether there is a valid session for the user to connect to the target cluster; if there is a valid session, return the session identifier to the client; Step 2 is divided into the following steps:

[0054] Query the session registry for available sessions using the user ID, target cluster ID, and cluster terminal type.

[0055] If the session exists, the session identifier is returned to the client.

[0056] Step 3: If no valid session exists, create an isolated operation Pod in the management cluster and create a corresponding temporary RBAC permission set in the target cluster. At the same time, generate a unique session identifier to bind the Pod, and inject the KubeConfig information corresponding to the RBAC into the Pod. Step 3 is divided into the following steps:

[0057] Create an operation Pod with security isolation properties in the management cluster;

[0058] Generate a globally unique session identifier, bind it to the Pod, and register it in the session registry;

[0059] Generates a cross-namespace RBAC permission set based on user permission data, which may include roles and role bindings for multiple target clusters.

[0060] Generate the KubeConfig configuration corresponding to the RBAC permission set through the RBAC rendering module. The configuration includes the API Server endpoint, certificate authority data, and the Bearer Token obtained from the ServiceAccount.

[0061] Create the RBAC permission set in the target cluster and inject the complete KubeConfig into the Pod environment;

[0062] The RBAC permission set includes: Role, RoleBinding, and ServiceAccount.

[0063] Please refer to Figure 4 , Figure 4 A logical flow chart of a client connecting to the Pod in a dynamic permission Web terminal management method in a multi-cluster environment according to an example of the present disclosure is shown.

[0064] Step 4: Establish a connection between the client and the Pod through Websocket, so that the client can execute Shell commands in the Pod and access the target cluster;

[0065] The client sends a connection request carrying the session identifier via Websocket;

[0066] The server is associated with the corresponding Pod according to the session identifier;

[0067] A Websocket bidirectional communication tunnel is established to forward the client input to the Shell environment of the Pod.

[0068] Please refer to Figure 5 , Figure 5 A logic flow chart of permission verification for sending a request to a target cluster in a dynamic permission Web terminal management method for a multi-cluster environment of an embodiment of the present disclosure.

[0069] Step 5: When the client accesses the target cluster through the Pod, it is only allowed to access resources defined by the RBAC permission set;

[0070] The client operates the Pod terminal to access resources on the target cluster;

[0071] The access request passes through the API server of the target cluster, obtains the Bearer Token and resolves the ServiceAccount. The service account and the corresponding RBAC permission set are used to determine whether the request has permission to access the corresponding resource. If the permission is granted, the request is allowed; if not, a prompt is displayed indicating insufficient access rights.

[0072] Step 6: After the client disconnects, if no further connection is requested, the server automatically reclaims the Pod resources and the temporary RBAC resources of the target cluster based on a timeout mechanism;

[0073] Monitoring the client connection status;

[0074] If the connection is disconnected for more than the set time, the deletion process is triggered, and the session in the session registry, the Pod corresponding to the session identifier, and the temporary RBAC resources of the target cluster are deleted through the session identifier;

[0075] Archive the Pod's operation logs to persistent storage.

[0076] In one possible implementation, assume that an operation and maintenance personnel needs to operate a cluster named Cluster-Prod-001 through a web terminal:

[0077] The operator clicks "New Session" on the web interface and selects the target cluster, cluster-prod-001. The server searches the session registry for an existing session based on the user ID, target cluster ID, and terminal type in the client's request. If no session is found, it creates a session using the user ID, target cluster ID, and terminal type, and generates a unique session ID, a1b2c3d4.

[0078] Create a temporary Pod named cluster-prod-001-a1b2c3d4. Use the user ID to find the user's permissions in the target cluster in the permissions management module. Based on the permissions list, create an RBAC resource configuration with a session ID tag and apply it to the target cluster. Generate a KubeConfig containing the ServiceAccount Token information and inject it into the Pod. Finally, return the session ID to the client.

[0079] The client requests a temporary Pod with the unique identifier a1b2c3d4. The server verifies that the user has access rights by obtaining the unique identifier and user identity information. The server finds the associated Pod, establishes a terminal connection, and upgrades the client's request to a WebSocket connection. It receives the client's input and forwards it to the Pod, and forwards the Pod's terminal response to the client, forming an operation terminal from the client to the target Pod.

[0080] The operations and maintenance personnel execute the command "kubectl get pods -n kube-system" in the terminal. This actually causes the temporary Pod to send a request to the API Server of the target cluster. The API Server uses the token in the request to confirm the requester's ServiceAccount information and the relevant RBAC to determine whether the requester has access permission. The ServiceAccount's RoleBinding is bound to a Role resource that allows reading the bcs-system namespace, so the request is allowed.

[0081] The target cluster API server receives the request, processes it, and returns it to the Pod terminal. The terminal content is synchronized to the client in real time, and a list of Pods in the kube-system namespace is listed.

[0082] The operations and maintenance personnel executed the command "kubectl delete pod -n test test-pod" on the terminal. The kubectl command sent an HTTP request to the target cluster. The API server of the target cluster received the request and confirmed the user's identity based on the token. The API server searched the relevant RBAC account and found no permission to delete the bcs-system namespace. The operation was rejected and a permission error was returned.

[0083] The Pod terminal receives the returned error message and returns it to the client in real time;

[0084] After the operation and maintenance personnel disconnect, the server starts a 10-minute countdown. During this period, the Pod remains running and receives the server's reconnection to enable the client to quickly reconnect;

[0085] If the operator is disconnected for more than 10 minutes, the session cleanup mechanism is triggered. The session is deleted from the session registry and the Pod bound to the session is deleted. The temporary RBAC resources created in the target cluster are quickly deleted using the session identifier label, completing resource recovery. Finally, the user's operation records in the Pod are archived.

[0086] During a session, if a user's permissions change, the permission verification module will synchronously render the RBAC of the new permissions and apply them to the target cluster to ensure that the new permissions are synchronized to the user.

[0087] In a second aspect, an embodiment of the present application further provides a dynamic permission web terminal management system for a multi-cluster environment, including:

[0088] Session management module: executes step 1, generates a session identifier and creates a Pod;

[0089] Communication proxy module: executes step 2 to establish a WebSocket connection between the client and the Pod;

[0090] Permission verification module: executes step 3 to manage the user's operation permissions on multi-cluster resources.

[0091] In a third aspect, embodiments of the present application further provide an electronic device comprising a memory and a processor. The memory stores instructions, which are loaded and executed by the processor to implement the steps of the above method. The memory and the processor communicate with each other via an internal connection path.

[0092] The device may also preferably include a communication interface, which is used for communicating with external devices and transmitting data interactively.

[0093] It should be noted that the memory may include a high-speed RAM memory, and may also include a non-volatile memory, such as at least one disk memory.

[0094] In a specific implementation, if the memory, processor, and communication interface are integrated on a single chip, they can communicate with each other via an internal interface. If the memory, processor, and communication interface are implemented independently, they can be connected to each other via a bus and communicate with each other.

[0095] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, which implements the steps of the above method when executed by a processor.

[0096] It should be understood that the computer-readable storage medium is any data storage device that can store data or programs that can be subsequently read by a computer system. Examples of computer-readable storage media include read-only memory, random access memory, CD-ROMs, HDDs, DVDs, magnetic tapes, and optical data storage devices. Computer-readable storage media can also be distributed among network-coupled computer systems so that computer-readable code can be stored and executed in a distributed manner.

[0097] The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to wireless, wire, optical cable, radio frequency (RF), etc., or any suitable combination thereof.

[0098] In some embodiments, the computer-readable storage medium may be non-transitory.

[0099] In the above embodiments, all or part of the embodiments may be implemented using software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments may be implemented in the form of a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions according to the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0100] In the description of this specification, any process or method description in a flowchart or otherwise described herein can be understood to represent a module, segment or portion of code including one or more executable instructions for implementing the steps of a specific logical function or process. And the scope of the preferred embodiments of the present application includes other implementations, in which the functions may not be performed in the order shown or discussed, including performing the functions in a substantially simultaneous manner or in the reverse order depending on the functions involved.

[0101] The logic and / or steps represented in the flowchart or otherwise described herein may be considered, for example, as a sequenced list of executable instructions for implementing the logical functions, and may be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processor, or other system that can fetch and execute instructions from an instruction execution system, apparatus, or device).

[0102] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present application, which are used to illustrate the technical solutions of the present application rather than to limit them. The scope of protection of the present application is not limited thereto. Although the present application has been described in detail with reference to the aforementioned embodiments, ordinary technicians in this field should understand that any technician familiar with this technical field can still modify the technical solutions recorded in the aforementioned embodiments within the technical scope disclosed in the present application, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be covered by the scope of protection of the present application.

Claims

1. A dynamic permission Web terminal management method for a multi-cluster environment, characterized in that: include: Step 1: Receive a cluster session creation request from a client, the request including a target cluster identifier and a requested terminal type; Step 2: Query the session registry to check whether there is a valid session for the user to connect to the target cluster; if there is a valid session, return the session identifier to the client; Step 3: If no valid session exists, create an isolated operation Pod in the management cluster and create a corresponding temporary RBAC permission set in the target cluster. At the same time, generate a unique session identifier to bind the Pod, and inject the KubeConfig information corresponding to the RBAC into the Pod. The step 3 comprises: Step 3-1: Create an operation Pod with security isolation properties in the management cluster; Step 3-2: Generate a globally unique session identifier, bind it to the Pod, and register it in the session registry; Step 3-3: Generate a cross-namespace RBAC permission set based on user permission data, which includes roles and role bindings for multiple target clusters; Step 3-4: Generate the KubeConfig configuration corresponding to the RBAC permission set through the RBAC rendering module. The configuration contains the APIServer endpoint, certificate authority data, and the Bearer Token obtained from the ServiceAccount. Step 3-5: Create the RBAC permission set in the target cluster and inject the complete KubeConfig into the Pod environment; The RBAC permission set includes: Role, RoleBinding, and ServiceAccount; Step 4: Establish a connection between the client and the Pod through Websocket, so that the client can execute Shell commands in the Pod and access the target cluster; Step 5: When the client accesses the target cluster through the Pod, it is only allowed to access resources defined by the RBAC permission set; Step 6: After the client is disconnected, if no further connection is requested, the server automatically reclaims the Pod resources and the temporary RBAC resources of the target cluster based on the timeout mechanism.

2. The method for managing dynamic permission Web terminals in a multi-cluster environment according to claim 1, characterized in that: The step 2 includes: Step 2-1: Use the user identity, target cluster ID, and cluster terminal type to query the session registry to see if there is an available session. Step 2-2: If the session exists, the session identifier is returned to the client.

3. The method for managing dynamic permission Web terminals in a multi-cluster environment according to claim 1, wherein: The step 4 comprises: Step 4-1: The client sends a connection request carrying the session identifier via Websocket; Step 4-2: The server is associated with the corresponding Pod according to the session identifier; Step 4-3: Establish a Websocket bidirectional communication tunnel and forward the client input to the Shell environment of the Pod.

4. The method for dynamic permission Web terminal management in a multi-cluster environment according to claim 1, characterized in that: The step 5 comprises: Step 5-1: The client operates the Pod terminal to access resources on the target cluster; Step 5-2: The access request passes through the API Server of the target cluster, obtains the Bearer Token and resolves the ServiceAccount. Based on the ServiceAccount and the corresponding RBAC permission set, it is determined whether the request has the right to access the corresponding resource; if the permission is granted, the request is allowed; if not, a prompt is displayed indicating insufficient access rights.

5. The method for managing dynamic permission Web terminals in a multi-cluster environment according to claim 1, wherein: The step 6 comprises: Step 6-1: Monitor the client connection status; Step 6-2: If the connection is disconnected for more than the set time, the deletion process is triggered, and the session in the session registry, the Pod corresponding to the session identifier, and the temporary RBAC resources of the target cluster are deleted through the session identifier; Step 6-3: Archive the Pod's operation log to persistent storage.

6. An electronic device, characterized in that: include: a memory for storing one or more programs; A processor, configured to run the program stored in the memory to implement the method according to any one of claims 1 to 5.

7. A computer-readable storage medium storing at least one program, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 5 is implemented.

Images