Container login method and system

Abstract

The invention provides a container login method and system, and the method comprises the steps: a first login proxy service node in a login proxy service cluster verifies the validity of a Node connection token carried by a reverse connection request when receiving the reverse connection request of any login Agent in at least one Kubernetes cluster, and after the validity verification of the Node connection token is passed, the first login proxy service node in the login proxy service cluster sends the reverse connection request to any login Agent in the Kubernetes cluster; establishing a reverse tunnel with any one login Agent; when a second login proxy service node in the login proxy service cluster receives a container login request for the to-be-logged-in container, the unified authority management module is called to perform container login authority verification; and if the container login permission verification is successful, forwarding the container login request to a login Agent corresponding to the to-be-logged container through a reverse tunnel corresponding to the to-be-logged container, so that the login Agent corresponding to the to-be-logged container executes login of the to-be-logged container, and returns a login success response to the second login proxy service node. According to the embodiment of the invention, container login can be carried out under the condition of improving security.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular, to a container login method and system. Background Art

[0002] At present, with the gradual maturity of cloud native technology, more and more enterprises use Kubernetes (K8s, a container cluster management system) as the new generation of infrastructure standard. In K8s, the container technology, as the carrier of K8s technology application, has an inseparable relationship with K8s. The containerization technology is a lightweight virtualization technology based on the operating system kernel, with characteristics such as consistency, isolation, and portability, which solves the contradiction between development and operation and maintenance. In the management system of K8s, a pod is the smallest unit managed by K8s, which is a combination of one or more containers. Inside an enterprise, application services are usually deployed in the form of pods. In order to troubleshoot application service failures, view the running status of application services, analyze service running data, etc., developers or operation and maintenance personnel need to log in to the containers of the pods. However, related technologies usually log in to the containers through methods such as the K8s management tool kubectl, resulting in excessive permissions of kubectl and posing a relatively high security risk. Based on this, there is currently no good solution for container login while improving security. Summary of the Invention

[0003] In view of this, embodiments of the present invention provide a container login method and system to solve problems such as relatively high security risks caused by related technologies. That is to say, after establishing a reverse tunnel between the login Agent and the login proxy service node in the embodiments of the present invention, when a login proxy service node receives a container login request for a container to be logged in, it can perform container login permission verification, and only after the container login permission verification is successful, forward the container login request to the corresponding login Agent through the corresponding reverse tunnel to achieve container login, so as to perform container login while improving security, that is, effectively reduce the security risk of container login.

[0004] According to one aspect of the embodiments of the present invention, a container login method is provided. The container login method is applied to a container login system, the container login system includes a login proxy service cluster and at least one Kubernetes cluster, the login proxy service cluster includes at least one login proxy service node, a Kubernetes cluster includes at least one Node node, and a Node node includes a login Agent. The method includes:

[0005] When the first login proxy service node in the login proxy service cluster receives a reverse connection request from any one of the login Agents in the at least one Kubernetes cluster, it verifies the validity of the Node connection token carried in the reverse connection request, and after passing the verification of the Node connection token validity, establishes a reverse tunnel with any one of the login Agents; wherein, the first login proxy service node is any one of the login proxy service nodes in the login proxy service cluster, and each of the login Agents in the at least one Kubernetes cluster supports establishing a reverse tunnel with each of the login proxy service nodes in the login proxy service cluster;

[0006] When the second login proxy service node in the login proxy service cluster receives a container login request for a container to be logged in, it calls the unified permission management module to perform container login permission verification; if the container login permission verification is successful, it forwards the container login request to the login Agent corresponding to the container to be logged in through the reverse tunnel corresponding to the container to be logged in, so that the login Agent corresponding to the container to be logged in executes logging in to the container to be logged in and returns a login success response to the second login proxy service node;

[0007] Wherein, the second login proxy service node is any one of the login proxy service nodes in the login proxy service cluster, the container to be logged in is any one of the containers in the at least one Kubernetes cluster, a reverse tunnel corresponding to a container is a reverse tunnel between the login Agent on the Node node where the corresponding container is located and the login proxy service cluster, and a login Agent corresponding to a container is the login Agent on the Node node where the corresponding container is located.

[0008] According to another aspect of the embodiments of the present invention, there is provided a container login system, the container login system includes: the login proxy service cluster and at least one Kubernetes cluster, the login proxy service cluster includes at least one login proxy service node, a Kubernetes cluster includes at least one Node node, and a Node node includes one login Agent;

[0009] The first login proxy service node in the login proxy service cluster is configured to, when receiving a reverse connection request from any one of the login Agents in the at least one Kubernetes cluster, verify the validity of the Node connection token carried in the reverse connection request, and establish a reverse tunnel with the any one of the login Agents after passing the validity verification of the Node connection token; wherein, the first login proxy service node is any one of the login proxy service nodes in the login proxy service cluster, and each of the login Agents in the at least one Kubernetes cluster supports establishing a reverse tunnel with each of the login proxy service nodes in the login proxy service cluster.

[0010] The second login proxy service node in the login proxy service cluster is configured to, when receiving a container login request for a container to be logged in, call the unified privilege management module to perform container login privilege verification; if the container login privilege verification is successful, forward the container login request to the login Agent corresponding to the container to be logged in through the reverse tunnel corresponding to the container to be logged in, so that the login Agent corresponding to the container to be logged in executes logging in to the container to be logged in and returns a login success response to the second login proxy service node.

[0011] Wherein, the second login proxy service node is any one of the login proxy service nodes in the login proxy service cluster, the container to be logged in is any one of the containers in the at least one Kubernetes cluster, a reverse tunnel corresponding to a container is a reverse tunnel between the login Agent on the Node where the corresponding container is located and the login proxy service cluster, and a login Agent corresponding to a container is the login Agent on the Node where the corresponding container is located.

[0012] According to another aspect of the embodiments of the present invention, there is provided an electronic device, which includes a processor and a memory for storing a program; wherein, the program includes instructions, and when the instructions are executed by the processor, the processor is caused to execute the method mentioned above.

[0013] According to another aspect of the embodiments of the present invention, there is provided a non-transitory computer-readable storage medium storing computer instructions, and the computer instructions are used to cause a computer to execute the method mentioned above.

[0014] When the first login proxy service node in the embodiment of the present invention receives a reverse connection request from any login Agent in at least one Kubernetes cluster, it can verify the validity of the Node connection token carried in the reverse connection request, and establish a reverse tunnel with any login Agent after passing the verification of the Node connection token validity; wherein, the first login proxy service node is any login proxy service node in the login proxy service cluster, and each login Agent in at least one Kubernetes cluster supports establishing a reverse tunnel with each login proxy service node in the login proxy service cluster respectively. Correspondingly, when the second login proxy service node receives a container login request for a container to be logged in, it can call the unified permission management module to perform container login permission verification; if the container login permission verification is successful, it forwards the container login request to the login Agent corresponding to the container to be logged in through the reverse tunnel corresponding to the container to be logged in, so that the login Agent corresponding to the container to be logged in executes logging in to the container to be logged in and returns a login success response to the second login proxy service node; wherein, the second login proxy service node is any login proxy service node in the login proxy service cluster, the container to be logged in is any container in at least one Kubernetes cluster, the reverse tunnel corresponding to a container is the reverse tunnel between the login Agent on the Node where the corresponding container is located and the login proxy service cluster, and the login Agent corresponding to a container is the login Agent on the Node where the corresponding container is located. It can be seen that after establishing a reverse tunnel between the login Agent and the login proxy service node in the embodiment of the present invention, when a login proxy service node receives a container login request for a container to be logged in, it can perform container login permission verification, and only after the container login permission verification is successful, it forwards the container login request to the corresponding login Agent through the corresponding reverse tunnel to implement container login, and can perform container login under the condition of improving security, that is, effectively reducing the security risk of container login. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In the following description of the exemplary embodiments in conjunction with the drawings, more details, features and advantages of the present invention are disclosed, in the drawings:

[0016] Figure 1 FIG. shows a flowchart of a container login method according to an exemplary embodiment of the present invention;

[0017] Figure 2 FIG. shows a schematic diagram of a container login system according to an exemplary embodiment of the present invention;

[0018] Figure 3 FIG. shows a schematic diagram of a unified management center according to an exemplary embodiment of the present invention;

[0019] Figure 4 The flowchart shows another container login method according to an exemplary embodiment of the present invention;

[0020] Figure 5 The schematic diagram shows a data flow according to an exemplary embodiment of the present invention;

[0021] Figure 6 The schematic diagram shows another container login system according to an exemplary embodiment of the present invention;

[0022] Figure 7 The block diagram shows an exemplary electronic device capable of implementing the embodiments of the present invention. Detailed implementation manners

[0023] Embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although some embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. On the contrary, these embodiments are provided to more thoroughly and completely understand the present invention. It should be understood that the drawings and embodiments of the present invention are only for exemplary purposes and are not used to limit the protection scope of the present invention.

[0024] It should be understood that the steps described in the method embodiments of the present invention can be executed in different orders and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this regard.

[0025] As used herein, the term "including" and its variations are open-ended, that is, "including but not limited to". The term "based on" is "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The relevant definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc. mentioned in the present invention are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.

[0026] It should be noted that the modifications of "one" and "multiple" mentioned in the present invention are illustrative rather than restrictive. Those skilled in the art should understand that unless otherwise clearly specified in the context, it should be understood as "one or more".

[0027] The names of the messages or information exchanged between multiple devices in the embodiments of the present invention are only for illustrative purposes and are not used to limit the scope of these messages or information.

[0028] It should be noted that the embodiments of the present invention may relate to a container login system, which may include, but is not limited to, a login proxy service cluster and at least one Kubernetes cluster, etc. The embodiments of the present invention do not limit this. Among them, the login proxy service cluster includes at least one login proxy service node, a Kubernetes cluster includes at least one Node node (the device that runs the workload in the Kubernetes cluster), and a Node node includes a login Agent (agent, a program with a certain degree of autonomy). That is to say, a login Agent can be installed on a Node node. Optionally, a login Agent can also be referred to as a web (World Wide Web) login agent, a container web login agent, etc.

[0029] In the embodiments of the present invention, the execution subject of the container login method proposed by the embodiments of the present invention can be the container login system. That is to say, the container login method proposed by the embodiments of the present invention can be executed by the login proxy service cluster and at least one Kubernetes cluster included in the container login system (that is, it can be executed by the container login system). Optionally, a node (such as a login proxy service and a Node node) can be an electronic device; based on this, the container login system can include one or more electronic devices, that is, the container login system can be composed of one or more electronic devices. Then, the execution subject of the container login method proposed by the embodiments of the present invention can be one or more electronic devices, that is, it can be one or more electronic devices that make up the container login system, etc.

[0030] Optionally, the electronic device can be a terminal (i.e., a client) or a server. Among them, the terminals mentioned here can include, but are not limited to: smart phones, tablet computers, laptop computers, desktop computers, smart watches, intelligent voice interaction devices, smart home appliances, vehicle-mounted terminals, etc. The servers mentioned here can be independent physical servers, or a server cluster or distributed system composed of multiple physical servers, or cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), as well as big data and artificial intelligence platforms, etc.

[0031] Based on the above description, an embodiment of the present invention provides a container login method, which can be applied to a container login system. The container login system includes a login proxy service cluster and at least one Kubernetes cluster. The login proxy service cluster includes at least one login proxy service node, a Kubernetes cluster includes at least one Node node, and a Node node includes a login Agent. That is, the container login method can be executed by the above-mentioned container login system, that is, by the electronic devices constituting the container login system. For the sake of convenience of description, hereinafter, the example of the container login system executing the container login method will be used for illustration, that is, the example of the login proxy service cluster and at least one Kubernetes cluster in the container login system executing the container login method will be used for illustration. As Figure 1 shown, the container login method may include the following steps S101-S102:

[0032] S101. When the first login proxy service node in the login proxy service cluster receives a reverse connection request from any login Agent in at least one Kubernetes cluster, it verifies the validity of the Node connection token carried in the reverse connection request, and after passing the verification of the validity of the Node connection token, it establishes a reverse tunnel with any login Agent.

[0033] Wherein, the first login proxy service node is any login proxy service node in the login proxy service cluster, and each login Agent in at least one Kubernetes cluster supports establishing a reverse tunnel with each login proxy service node in the login proxy service cluster respectively. Optionally, the login proxy service cluster may also be referred to as a web login proxy, a web login proxy service cluster, a login proxy service background, etc., and the embodiments of the present invention do not limit this.

[0034] In an embodiment of the present invention, each login proxy service node in the login proxy service cluster can enable a reverse tunnel listening service and wait for a reverse connection from the login Agent on the Node node. That is to say, it can wait for the login Agent to send a reverse connection request, and the reverse connection request can be used to request the establishment of a reverse tunnel. Based on this, when the login Agent requests to establish a reverse tunnel, the login proxy service cluster (i.e., the login proxy service node in the login proxy service cluster that receives the reverse connection request) can verify the validity of the corresponding Node connection token (which can also be expressed as a Node-join (connection, join)-token). And only when the corresponding Node connection token is valid (i.e., the Node connection token generated for the current login proxy service cluster) can a reverse tunnel be established with the login proxy service cluster (i.e., establish a reverse tunnel with the group of login proxy service nodes in the login proxy service set), which can improve security. Based on this, when the first login proxy service node verifies the validity of the Node connection token carried in the reverse connection request, it can determine whether the Node connection token carried in the reverse connection request is the Node connection token among at least one Node connection token. The at least one Node connection token can include all the Node connection tokens generated by the login proxy service cluster. When the Node connection token carried in the reverse connection request is the Node connection token among at least one Node connection token (i.e., there is a Node connection token in the at least one Node connection token that is the same as the Node connection token carried in the reverse connection request), it can be determined that the Node connection token validity verification is passed, that is, it can be determined that the Node connection token carried in the reverse connection request is invalid. When the Node connection token carried in the reverse connection request is not the Node connection token among at least one Node connection token (i.e., there is no Node connection token in the at least one Node connection token that is the same as the Node connection token carried in the reverse connection request), it can be determined that the Node connection token validity verification is not passed, that is, it can be determined that the Node connection token carried in the reverse connection request is valid.

[0035] Optionally, to ensure the stability of the service, the login proxy service can be deployed distributively, which is divided into a master node (i.e., the master node of the login proxy service) and slave nodes (i.e., the slave nodes of the login proxy service). That is to say, at least one login proxy service node may include the master node of the login proxy service and at least one slave node of the login proxy service. Among them, the master node of the login proxy service is responsible for generating tokens for the slave nodes of the login proxy service to join. After obtaining the authentication token, the slave nodes of the login proxy service can connect to the master node of the login proxy service for communication, and synchronize the running status of the login agents on all Node nodes with each other. The master and each slave node together form a login proxy service cluster. Each login service proxy node in the login proxy service cluster can open a reverse tunnel listening port (to enable the reverse tunnel listening service), wait for the reverse connection of the login agent, and at the same time listen for the user's web login request (i.e., the container login request) and forward the container login request to the corresponding reverse tunnel. Optionally, the connection between a login agent and the login proxy service cluster (i.e., the login proxy service node in the login proxy service cluster) can be a TCP (Transmission Control Protocol) long connection. Optionally, each login proxy service node in the login proxy service cluster can provide a keep-alive mechanism and start a detection timing task to send keep-alive detection messages to each login agent in at least one Kubernetes cluster, so as to maintain the TCP connection. It can be seen that the embodiment of the present invention can enable the token generation service of the login proxy service cluster.

[0036] Based on this, the main node of the login proxy service can generate at least one slave node join token (which can also be expressed as slave-join-token. The at least one slave node join token can be used for each login proxy service slave node to connect to the login proxy service cluster, that is, to connect to the main node of the login proxy service). That is, the login proxy service cluster can generate at least one slave node join token through the main node of the login proxy service, so that after each of the at least one login proxy service slave nodes obtains one of the at least one slave node join tokens, it can connect to the main node of the login proxy service through the obtained slave node join token for communication to join the login proxy service cluster. In the embodiment of the present invention, the login proxy service slave node is only allowed to join the login proxy service cluster after obtaining the slave node join token in the at least one slave node join token generated by the main node of the login proxy service, which can improve security. Optionally, the slave node join tokens obtained by different login proxy service slave nodes can be different; optionally, the main node of the login proxy service can send a slave node join token to each login proxy service slave node respectively, or a slave node join token can also be configured in one login proxy service slave node through offline configuration, etc.; the embodiment of the present invention does not limit this.

[0037] In this case, the login proxy service cluster can enable the cluster authentication service and wait for the login proxy service slave node to join; optionally, when the main node of the login proxy service in the login proxy service cluster receives a cluster join request from any login proxy service slave node, the main node of the login proxy service can verify the validity of the slave node join token carried in the cluster join request; when the slave node join token carried in the cluster join request is the slave node join token in the at least one slave node join token, it can be determined that the slave node join token carried in the cluster join request is valid, that is, it can be determined that the validity verification of the slave node join token is passed; when the slave node join token carried in the cluster join request is not the slave node join token in the at least one slave node join token, it can be determined that the slave node join token carried in the cluster join request is invalid, that is, it can be determined that the validity verification of the slave node join token is not passed; further, after determining that the validity verification of the slave node join token is passed, a connection can be established with any login proxy service slave node, so that any login proxy service slave node joins the login proxy service cluster.

[0038] Correspondingly, the login proxy service master node can generate at least one Node connection token (that is, the login proxy service cluster can generate at least one Node connection token through the login proxy service master node, and the at least one Node connection token can be used for each login Agent to establish a connection with each login proxy service node), so that after any login Agent obtains one of the at least one Node connection tokens, it can send reverse connection requests to each login proxy service node through the obtained Node connection token, so as to realize the above-mentioned sending of reverse connection requests to the first login proxy service node; based on this, reverse tunnels can be established with each login proxy service node respectively. In the embodiment of the present invention, one login Agent can establish reverse tunnels with each login proxy service node in the login proxy service cluster respectively. Optionally, the Node connection tokens obtained by different login Agents can be different.

[0039] Optionally, a Kubernetes cluster includes a management node, such as Figure 2 shown; based on this, for any one of the at least one Kubernetes clusters, the management node in any one of the Kubernetes clusters can obtain a Node connection token from the login proxy service cluster, and send the obtained Node connection token to each Node node in any one of the Kubernetes clusters respectively, so that the login Agent on each Node node in any one of the Kubernetes clusters can obtain one of the at least one Node connection tokens. Optionally, the management node in any one of the Kubernetes clusters can call the login proxy service background gateway service to obtain the Node connection token; optionally, the number of Node connection tokens obtained by the management node in any one of the Kubernetes clusters can be the number of Node nodes in any one of the Kubernetes clusters, so that a Node connection token can be sent to one Node node respectively. At this time, the Node connection tokens on different Node nodes can be different, that is, the Node connection tokens obtained by different login Agents can be different. Based on this, any login Agent can start and obtain the Node connection token passed through by the management node in the Kubernetes cluster where the login Agent is located, so as to poll all the login proxy service nodes in the login proxy service cluster, and establish a reverse tunnel connection with the reverse tunnel listening ports opened by all the login proxy service nodes in the login proxy service cluster, which can effectively improve the stability of the container login system, so as to ensure that the user can log in to the corresponding container when logging in to any login proxy service node in the login proxy service cluster; correspondingly, any login Agent can also wait for the user's container login request and operation command request, etc. in the established reverse tunnel.

[0040] Optionally, the management node in any Kubernetes cluster can also start the pods to which the login agents on each Node node in any Kubernetes cluster belong in the form of daemonset deployment (a deployment method that can ensure that there is exactly one login Agent on one Node node), and mount the unixsocket (an efficient inter-process communication method on the same host) file for communicating with the container into the pods to which the login agents on each Node node in any Kubernetes cluster belong, so that a Node node can support scheduling on the corresponding Node node through a deployed login Agent; that is to say, at this time, a login Agent can be used to implement container scheduling on the Node node where it is located. It can be seen that the embodiment of the present invention can ensure that only one web login Agent is deployed on each host (i.e., Node node) through daemonset deployment, and can automatically complete scheduling on the Node node, reducing the complexity of management; moreover, the web login Agent is deployed in the pod, and resource restrictions can be made based on the pod, avoiding the web login Agent from affecting other services on the host, and at the same time reducing the attack surface; in addition, the web login agent usually communicates with the container background based on the local unixsocket file, and the UNIX (an operating system) domain socket is used for communication between local processes. This method is more efficient than the network socket, can only be accessed by local clients, and is also more secure than exposing the interface externally through tcp.

[0041] Optionally, the management node in any Kubernetes cluster can also initiate a timed data synchronization task to regularly synchronize the status indication data of each Node node in any Kubernetes cluster to each logged-in proxy service node. Optionally, the status indication data of a Node node may include, but is not limited to, at least one of the following: the node status information of the corresponding Node node (i.e., the status information of the node) and the container status information of each container in the corresponding Node node (i.e., the status information of the container), etc., and the embodiments of the present invention do not limit this; exemplarily, it may also include the Agent status information of the logged-in Agent on the corresponding Node node, etc. Optionally, the status information of a status object (such as a node, a container, and a logged-in Agent, etc.) (such as node status information, container status information, and Agent status information, etc.) may include, but is not limited to, at least one of the following: the life cycle of the corresponding status object, the current online status (such as whether it is currently online), the life status (such as stopped, destroyed, and started, etc.), etc., and the embodiments of the present invention do not limit this; for example, the status information of a logged-in Agent (i.e., Agent status information) may also include the node identifier (such as node name or node number, etc.) of the logged-in proxy service node connected to the corresponding logged-in Agent, etc. Optionally, the management node in any Kubernetes cluster can also regularly synchronize the status information of any Kubernetes cluster (such as the life cycle of the cluster, etc.) to each logged-in proxy service node.

[0042] Optionally, for any login Agent in at least one Kubernetes cluster (i.e., any one of the login Agents on all Node nodes in at least one Kubernetes cluster), any login Agent can also start a timed heartbeat reporting task and / or a timed indication data reporting task, etc., which are not limited in the embodiments of the present invention; among them, the timed indication data reporting task of any login Agent can complete data synchronization with the management node in the Kubernetes cluster where any login Agent is located, so that any login proxy service node can verify the consistency check between the status indication data reported by any login Agent and the status indication data reported by the management node in the Kubernetes cluster where any login Agent is located. In other words, any login Agent can report a heartbeat to the login proxy service cluster at regular intervals to determine to maintain a connection with the login proxy service cluster, that is, report a heartbeat to each login proxy service node to determine to maintain a connection with each login proxy service node (i.e., the above TCP connection); and / or, any login Agent reports the status indication data of the Node node where any login Agent is located to the login proxy service cluster at regular intervals, that is, reports the status indication data of the Node node where any login Agent is located to each login proxy service node at regular intervals.

[0043] It should be noted that the timing times of different timed tasks (i.e., the interval duration for triggering the corresponding timed tasks) can be the same or different, which are not limited in the embodiments of the present invention.

[0044] S102. When the second login proxy service node in the login proxy service cluster receives a container login request for a container to be logged in, it calls the unified permission management module to perform container login permission verification; if the container login permission verification is successful, it forwards the container login request to the login Agent corresponding to the container to be logged in through the reverse tunnel corresponding to the container to be logged in, so that the login Agent corresponding to the container to be logged in executes the login to the container to be logged in and returns a login success response to the second login proxy service node.

[0045] Among them, the second login proxy service node is any login proxy service node in the login proxy service cluster, the container to be logged in is any container in at least one Kubernetes cluster, the reverse tunnel corresponding to a container is the reverse tunnel between the login Agent on the Node node where the corresponding container is located and the login proxy service cluster, and the login Agent corresponding to a container is the login Agent on the Node node where the corresponding container is located. Optionally, the second login proxy service node can be the same as the first login proxy service node (i.e., the same login proxy service node) or different (i.e., different login proxy service nodes), which are not limited in the embodiments of the present invention.

[0046] Optionally, the container login system may further include a login proxy service front-end (which may also be referred to as a web login proxy service front-end). Based on this, when the login proxy service front-end detects a proxy service login request from a target user, it may send the proxy service login request to the login proxy service cluster (i.e., the login proxy service background). For example, the target user can access the login proxy service front-end through a web front-end browser to execute the proxy service login request. Correspondingly, after receiving the proxy service login request, the login proxy service cluster may determine whether the target user is logged in (i.e., whether logged in to the above-mentioned login proxy service background). If the target user is not logged in, it performs identity authentication for the target user (i.e., authenticates whether the target user has the login permission for the above-mentioned login proxy service background), and prompts the target user that the authentication fails when the authentication fails (such as sending an authentication failure indication message to the login proxy service front-end to prompt the user that the authentication fails), and after the authentication is successful, enables the login proxy service front-end to display a container login interface, and the container login interface supports the target user to execute the above-mentioned container login request. Optionally, the target user can be any user. It should be noted that the specific content of the container login interface in the embodiments of the present invention is not limited. Exemplarily, the container login interface may include selecting a Kubernetes cluster - Node node - container to execute the container login request. Optionally, the above-mentioned proxy service login request may refer to a login request for the login proxy service background, or may refer to any other data request (such as a container login request, etc. In this case, when receiving any data request from the target user, it may first determine whether the target user is logged in to the above-mentioned login proxy service background, and perform identity authentication when the target user is not logged in), etc. The embodiments of the present invention do not limit this. For the convenience of description, hereinafter, it will be described by taking the proxy service login request may refer to a login request for the login proxy service background as an example. Optionally, when the target user performs identity authentication, the unified user authentication center (Central Authentication Service, CAS) within the enterprise can be called for identity authentication; or, the unified user identity authentication module in the unified authentication management center can also be called for identity authentication, etc. The embodiments of the present invention do not limit this. Among them, the unified authentication management center may include but is not limited to at least one of the following: the unified user identity authentication module and CAS, etc. The embodiments of the present invention do not limit this. Among them, the unified user identity authentication module and the unified authentication management center, etc. can effectively overcome the defects of decentralized user management and authentication, and provide efficient, secure, reliable, and scalable identity authentication services.

[0047] Optionally, the container login system further includes a unified management center; optionally, the unified management center may include, but is not limited to, at least one of the following: the above-mentioned unified authentication management center, unified permission management center, unified operation command management center, unified audit management center, unified user web login management center, etc., as Figure 3 shown; the embodiments of the present invention are not limited thereto. Optionally, the unified permission management center (the main function of this management center is to ensure the permission security of container login, and only users with permissions are allowed to log in to the corresponding container) may include, but is not limited to, at least one of the following: a unified permission application function module (supporting permanent permission application, temporary permission application (meeting the scenario requirements of temporary container login), and / or supporting fine-grained permission control within the container, such as Root permission: having administrator permission, Work permission: having limited resource access permission, other permissions: having limited resource access permission, which can be provided flexibly according to the actual situation, etc.), a unified permission approval function module (supporting the approval of user permission applications, and can provide different approval node configurations according to different dimensions to ensure the rationality and compliance of permission applications), a unified permission verification function module (during the process of a user logging in to a container, it can perform real-time verification on the user's permission to log in to the container (i.e., the container login permission) to ensure security), a unified permission cleaning function module (providing a permission cleaning function, such as cleaning the user's permissions when the permission administrator finds that the user's permissions are unreasonable), etc., the embodiments of the present invention are not limited thereto; among them, the unified permission application function module and the unified permission approval function module jointly provide the permission application / approval function. Before a user requests to log in to a certain container, a corresponding application / approval process needs to be followed. Only after the approval can the user be assigned the permission to log in to the corresponding container. The purpose of the application / approval function is to standardize the process of user permission usage, prevent users from having excessive permissions, and the users logging in to the container can only operate limited resources within the container to ensure the security of container login; based on this, when calling the unified permission management module (i.e., the unified permission management center) to perform container login permission verification, the unified permission verification function module in the unified permission management center can be called to perform container login permission verification. It can be seen that the embodiments of the present invention can ensure the permission security of container login through the unified permission management center.

[0048] Optionally, the unified operation command management center (mainly used to restrict the operation commands of users after logging in to the container. For example, some users can only view the logs of online services after logging in to the container, and cannot update or modify files, etc.) may include but are not limited to at least one of the following: a unified operation command application function module (supporting users to apply for operation commands under specific containers, such as operations related to modifying files, starting processes, etc.), a unified operation command approval function module (supporting operation command approvers to approve operation commands under specific containers), a unified operation command blocking function module (when a user executes an operation command in the shell (a scripting program) environment after logging in, this module is responsible for analyzing and blocking the user's operation command to prevent the user from executing high-risk operation commands and affecting the online environment), etc. The embodiments of the present invention are not limited thereto.

[0049] Optionally, the unified audit management center may include, but is not limited to, at least one of the following: a unified permission audit function module (which can be used to support the audit of the source of user permissions (such as permission approvers, etc.) and the size of user permissions, can identify potential permission security risks, and when it is found that the user permissions are unreasonable, the user's permissions can be recovered and cleaned in a timely manner to ensure the reasonableness and compliance of user permissions), a unified user login audit function module (which can be used to support the multi-dimensional audit of user login to the container, such as whether the user login time is reasonable, whether the user login location is reasonable, user login time, user logout time, access frequency, etc.), a unified user operation command audit function module (which can be used to support the audit of the operation commands after the user logs in to the container, with each input of the user's operation command corresponding to each output of the operation command to identify potential risk commands (such as identifying commands that trigger alarms, modification or deletion commands executed on files that are not allowed to be modified or deleted, or commands without permissions, etc.) to achieve traceability after the event), a unified cluster activity audit module (which can include the status information of each Kubernetes cluster, each Node node, each container, etc., such as obtaining this status information from the background of the login proxy service), etc., and the embodiments of the present invention do not limit this. Based on this, the login proxy service cluster can record the user's login information through the unified audit management center; and / or, the login proxy service cluster can record the operation commands input by the user and / or the corresponding outputs through the unified audit management center; wherein, the unified audit management center supports data audit, and the data audit includes at least one of the following: login information audit and operation command audit. Then correspondingly, when recording the user's login information through the unified audit management center, the user's login information can be recorded through the same user login audit module in the unified audit management center, so as to conduct a login information audit on the user, such as whether the user's access frequency is greater than the preset access frequency threshold, etc.; and when recording the operation commands input by the user and / or the corresponding outputs through the unified audit management center, the operation commands input by the user and / or the corresponding outputs can be recorded through the same operation command audit module in the unified audit management center, so as to conduct an operation command audit on the user, such as whether the operation command has permissions, etc. Optionally, the login information of a user may include, but is not limited to, at least one of the following: the login time, access frequency, login location, etc. of the corresponding user, and the embodiments of the present invention do not limit this. Optionally, the preset access frequency threshold can be set according to experience or according to actual needs, and the embodiments of the present invention do not limit this. In this case, the various modules in the unified audit management center can cooperate with each other to identify potential security risks, such as excessive permissions, unauthorized operations, abnormal access, etc., to achieve traceability after the event and ensure the security of container login, etc.Optionally, in other embodiments, the unified audit management center may also actively record the user's login information, and / or actively record the operation commands input by the user and / or the corresponding outputs, that is, the corresponding records can be made without calling through the login proxy service cluster, etc.; the present invention does not limit this.

[0050] Optionally, the unified cluster activity audit module may obtain the status information of each cluster audit object in at least one Kubernetes cluster (that is, the unified cluster activity audit module in the unified audit management center may obtain the status information of each cluster audit object from the background of the login proxy service). A cluster audit object may include, but is not limited to, any one of the following: a Node node and a container. For example, a cluster audit object may also be a Kubernetes cluster. Then, the unified cluster activity audit module may respectively perform activity audits on each cluster audit object based on the status information of each cluster audit object to determine the abnormal objects in at least one Kubernetes cluster. Alternatively, the background of the login proxy service may call the unified cluster activity audit module to obtain the status information of each cluster audit object for activity auditing, etc. It should be noted that the audit strategy for performing activity audits on any cluster audit object in the embodiments of the present invention may be set according to experience or set according to actual requirements, and the embodiments of the present invention do not limit this; for example, it is possible to audit whether any cluster audit object is online to use the offline cluster audit object as an abnormal object, etc. Based on this, an abnormal object may refer to a cluster audit object that fails the activity audit.

[0051] Optionally, the unified user login web management center (which can be used to manage the node information for cluster registration, provide the front-end page resources for user access, and relevant data display, etc.) may include, but is not limited to, at least one of the following: a unified cluster management module (which can be used to monitor the registration capabilities of resources such as Node nodes, Pods, and containers in the K8S cluster, be responsible for managing and displaying all cluster, node, and container information, and be responsible for displaying user permissions), a unified user login management module (which can be used to display different front-end resources according to different requests, that is, be used to provide data display such as front-end page resources for user access), etc., and the embodiments of the present invention do not limit this.

[0052] Based on this, the login proxy service cluster can start the user web client (i.e., the front end of the login proxy service) to log in to the proxy listening service, wait for the connection of the front end of the login proxy service and perform forwarding; correspondingly, the unified management center service can be started to start the services of each management center in the unified management center, such as starting the unified authentication management center, the unified permission management center, the unified operation command management center, the unified audit management center, and the unified user web login management center, etc. Optionally, the login proxy service cluster can also start a timed synchronization cluster task to regularly synchronize data related to nodes and / or containers (such as status information, etc.) within each login proxy service node; and / or, it can regularly send keep-alive probe messages to maintain long connections with each login Agent to maintain stability, etc. Optionally, each login proxy service node in the login proxy service cluster can also regularly synchronize connection information between containers and Node nodes, Node connection tokens and other information, etc.

[0053] In summary, through the unified identity authentication function module provided in the embodiments of the present invention, the authentication system within the company can be accessed, unified identity acquisition and identity authentication can be provided, the credibility and reliability of identity authentication can be improved, and the unified permission management module can be provided to support users' permission applications and approvals for containers, enhancing permission security. At the same time, the unified audit module can record the user login / logout and user operation command input / output of containers, with strict permission applications / approvals before the event, strict records during the event, and strict security audits and tracking after the event, meeting certain security requirements, etc. In this case, the embodiments of the present invention can effectively reduce the coupling relationship between user login and the K8S management node, and at the same time do not need to pay attention to the management mode of multiple K8S clusters, and can provide a unified web login entrance.

[0054] When the first login proxy service node in the embodiment of the present invention receives a reverse connection request from any login Agent in at least one Kubernetes cluster, it can verify the validity of the Node connection token carried in the reverse connection request, and establish a reverse tunnel with any login Agent after passing the verification of the validity of the Node connection token; wherein, the first login proxy service node is any login proxy service node in the login proxy service cluster, and each login Agent in at least one Kubernetes cluster supports establishing a reverse tunnel with each login proxy service node in the login proxy service cluster respectively. Correspondingly, when the second login proxy service node receives a container login request for the container to be logged in, it can call the unified permission management module to perform container login permission verification; if the container login permission verification is successful, it forwards the container login request to the login Agent corresponding to the container to be logged in through the reverse tunnel corresponding to the container to be logged in, so that the login Agent corresponding to the container to be logged in executes the login of the container to be logged in and returns a login success response to the second login proxy service node; wherein, the second login proxy service node is any login proxy service node in the login proxy service cluster, the container to be logged in is any container in at least one Kubernetes cluster, the reverse tunnel corresponding to a container is the reverse tunnel between the login Agent on the Node where the corresponding container is located and the login proxy service cluster, and the login Agent corresponding to a container is the login Agent on the Node where the corresponding container is located. It can be seen that after the reverse tunnel is established between the login Agent and the login proxy service node in the embodiment of the present invention, when a login proxy service node receives a container login request for the container to be logged in, it can perform container login permission verification, and only after the container login permission verification is successful, it forwards the container login request to the corresponding login Agent through the corresponding reverse tunnel to implement container login, and container login can be performed while improving security, that is, the security risk of container login can be effectively reduced.

[0055] Based on the above description, an embodiment of the present invention further provides a more specific container login method. This container login method can be applied to a container login system. The container login system includes a login proxy service cluster and at least one Kubernetes cluster. The login proxy service cluster includes at least one login proxy service node. A Kubernetes cluster includes at least one Node node. A Node node includes a login Agent. That is, the container login method can be executed by the above-mentioned container login system, that is, it can be executed by the electronic devices constituting the container login system. For the convenience of description, hereinafter, the example of the container login system executing the container login method will be used for illustration, that is, the example of the login proxy service cluster and at least one Kubernetes cluster in the container login system executing the container login method will be used for illustration. Please refer to Figure 4 , the container login method may include the following steps S401 - S405:

[0056] S401, when the first login proxy service node in the login proxy service cluster receives a reverse connection request from any login Agent in at least one Kubernetes cluster, it verifies the validity of the Node connection token carried in the reverse connection request, and after passing the verification of the Node connection token validity, it establishes a reverse tunnel with any login Agent.

[0057] Optionally, the login proxy service background can open an interface to receive data for creating pods in at least one K8S cluster, which is used to maintain the mapping relationship between Node nodes and containers in PODs and permission lifecycle management, effectively reducing the coupling relationship between user logins and the K8S - APIserver service, avoiding the impact of user logins on the K8S cluster, and improving stability.

[0058] Optionally, the embodiment of the present invention can utilize the K8S - daemonset scheduling mechanism. When adding existing Node nodes and new Node nodes to the Kubernetes cluster, it can automatically deploy the web login agent and connect to the login proxy service background through the reverse tunnel without the need to start an additional port number, effectively reducing the attack surface and ensuring security. At the same time, the connection established through the reverse tunnel can avoid the problem that the container can only connect outwards but cannot be connected from the outside due to reasons such as configuring firewall rules. Based on this, the embodiment of the present invention does not affect the pod services already running online while reducing the management cost of the web login Agent. In addition, the communication between the web login agent and the container still maintains the local unixsocket without the need to open an additional tcp port, which can improve communication efficiency while reducing the attack surface.

[0059] S402, when the second login proxy service node in the login proxy service cluster receives a container login request for a container to be logged in, it calls the unified permission management module to perform container login permission verification; if the container login permission verification is successful, it forwards the container login request to the login Agent corresponding to the container to be logged in through the reverse tunnel corresponding to the container to be logged in, so that the login Agent corresponding to the container to be logged in executes the login of the container to be logged in and returns a login success response to the second login proxy service node.

[0060] Optionally, the number of login proxy service fronts can be one or more, and the embodiments of the present invention do not limit this; for example, one user can correspond to one login proxy service front (i.e., the client), and so on. Optionally, after the target user executes a proxy service login request at the login proxy service front, the login proxy service front can establish a websocket (a full-duplex communication protocol) connection with any login proxy service node in the login proxy service cluster (such as the second login proxy service node mentioned above). Among them, websocket allows the establishment of a persistent connection between the client and the server to achieve real-time data transmission; compared with the traditional HTTP (HyperText Transfer Protocol) request-response mode, the websocket connection has the advantages of low latency, high efficiency, and real-time performance. Based on this, the login proxy service front and the login proxy service cluster can communicate using websocket, which can meet certain real-time and persistent requirements and achieve low-latency real-time communication. It should be understood that when any login service node in the login proxy service cluster receives any data or any data request, etc., it can also be said that the login proxy service cluster receives any data or any data request, etc.; correspondingly, the login proxy service cluster receiving any data or any data request can also indicate that any login proxy service node in the login proxy service cluster receives any data or any data request, etc.

[0061] Optionally, after the login proxy service cluster receives a websocket connection (i.e., after the login proxy service node in the login proxy service cluster receives a websocket connection), the target user can select the container identifier of the container to be logged in on the container login interface displayed by the front end of the login proxy service to execute a container login request for the container to be logged in. Then, the front end of the login proxy service can send the container login request to the login proxy service cluster (i.e., send it to the login proxy service node in the login proxy service cluster connected to the front end of the login proxy service, such as the second login proxy service node), so as to call the unified permission management module to perform container login permission verification. Optionally, if the container login permission verification fails, the front end of the login proxy service can prompt the target user that there is no container login permission for the container to be logged in, and / or guide the target user to apply for container login permission for the container to be logged in. Optionally, the container to be logged in can be any container. Optionally, the container identifier of a container can be the container number of the corresponding container, or the container name of the corresponding container, etc. The embodiments of the present invention do not limit this.

[0062] Optionally, when the login Agent corresponding to the container to be logged in executes the login of the container to be logged in, it can log in through the docker exec method provided natively by the container (a method for executing a new command in a running container), or log in through the encapsulated grpc (a high-performance communication protocol)-sdk (software development kit), etc. The embodiments of the present invention do not limit this. Optionally, after the container login is successful, the login Agent corresponding to the container to be logged in can also direct the standard input, output, and error streams to the reverse tunnel (also called the reverse connection tunnel) corresponding to the container to be logged in.

[0063] Optionally, the reverse tunnel corresponding to a container may include the reverse tunnels between the login Agent on the Node where the corresponding container is located and each login proxy service node (i.e., the reverse tunnel between a login Agent and the login proxy service cluster may include the reverse tunnels between the corresponding login Agent and each login proxy service node); optionally, when the second login proxy service node forwards the container login request to the login Agent corresponding to the container to be logged in through the reverse tunnel corresponding to the container to be logged in, it may forward the container login request to the login Agent corresponding to the container to be logged in through the reverse tunnel between the login Agent on the Node where the container to be logged in is located and the second login proxy service node, that is, at this time, the container login request may be forwarded to the login Agent corresponding to the container to be logged in through the reverse tunnel between the login Agent on the Node where the container to be logged in is located and the second login proxy service node in the reverse tunnel corresponding to the container to be logged in. Optionally, the container login request may carry the container identifier of the container to be logged in, then the second login proxy service node may select the reverse tunnel between the login Agent on the Node where the container to be logged in is located and the second login proxy service node through the container identifier of the container to be logged in, so as to implement the forwarding of the container login request.

[0064] Further, after receiving the response of successful login, the login proxy service background may start the relevant function modules of the unified audit function management center, record the user's login information and the input and output of relevant operation commands, and so on.

[0065] S403. When the login proxy service cluster receives the target operation command input by the target user, it determines whether the target operation command is an operation command allowed to be executed by the target user.

[0066] In the embodiment of the present invention, the user may input an operation command on the established websocket channel.

[0067] Optionally, the login proxy service cluster receiving the target operation command may mean that the login proxy service node establishing a websocket connection with the login proxy service front end of the target user in the login proxy service cluster receives the target operation command; based on this, the login proxy service cluster determining whether the target operation command is an operation command allowed to be executed by the target user may mean that the login proxy service node receiving the target operation command determines whether the target operation command is an operation command allowed to be executed by the target user, and so on; for the convenience of description, hereinafter, it will be described by taking the login proxy service cluster determining whether the target operation command is an operation command allowed to be executed by the target user as an example.

[0068] Optionally, the login proxy service cluster can call the unified operation command management center (such as the unified operation command blocking function module in the unified operation command management center) to determine whether the target operation command is an operation command allowed to be executed by the target user, that is, to determine whether the target user has the command operation authority to execute the target operation command.

[0069] S404: If the target operation command is an impermissible operation command, prompt the target user to prohibit execution of the target operation command and / or guide the target user to apply for the target operation command.

[0070] Optionally, when the target operation command is an operation command that is not allowed to be executed by the target user, that is, the target user does not have the operation command authority to execute the target operation command, it can be determined that the target operation command is an impermissible operation command.

[0071] Optionally, when prompting the target user to prohibit executing the target operation command and / or guiding the target user to apply for the target operation command, the login proxy service cluster may send a prompt instruction to prohibit executing the target operation command and / or a guidance instruction to apply for the target operation command to the login proxy service front end, so that the login proxy service front end can prompt the target user to prohibit executing the target operation command and / or guide the target user to apply for the target operation command.

[0072] S405, if the target operation command is an allowed operation command, the target operation command is forwarded to the login Agent corresponding to the container to be executed through the reverse tunnel corresponding to the container to be executed targeted by the target operation command, so that the login Agent corresponding to the container to be executed forwards the target operation command to the container to be executed for execution, and returns the execution result of the target operation command to the login proxy service front end for display.

[0073] Optionally, when the target operation command is an operation command that is allowed to be executed by the target user, that is, when the target user has the operation command authority to execute the target operation command, the target operation command may be determined to be an allowed operation command.

[0074] Optionally, the container to be executed may be any container; illustratively, when the container to be executed is the target container, the data flow direction may be as follows: Figure 5 shown.

[0075] As can be seen, when the first login proxy service node in the embodiment of the present invention receives a reverse connection request from any login Agent in at least one Kubernetes cluster, it can verify the validity of the Node connection token carried in the reverse connection request, and establish a reverse tunnel with any login Agent after passing the verification of the validity of the Node connection token. Moreover, when the second login proxy service node receives a container login request for a container to be logged in, it can call the unified permission management module to perform container login permission verification; if the container login permission verification is successful, it forwards the container login request to the login Agent corresponding to the container to be logged in through the reverse tunnel corresponding to the container to be logged in, so that the login Agent corresponding to the container to be logged in executes the login of the container to be logged in and returns a login success response to the second login proxy service node. Further, when the login proxy service cluster receives a target operation command input by a target user, it can determine whether the target operation command is an operation command allowed to be executed by the target user; if the target operation command is a disallowed operation command, it prompts the target user to prohibit the execution of the target operation command and / or guides the target user to apply for the target operation command; if the target operation command is an allowed operation command, it forwards the target operation command to the login Agent corresponding to the container to be executed through the reverse tunnel corresponding to the container to be executed targeted by the target operation command, so that the login Agent corresponding to the container to be executed forwards the target operation command to be executed inside the container to be executed and returns the execution result of the target operation command to the front end of the login proxy service for display. As can be seen, the embodiment of the present invention can provide a unified secure login method for multiple containers under K8S management, can provide the ability for users to remotely log in to containers through the web, improve the efficiency and experience of daily operation and maintenance, and ensure the security of login from multiple perspectives; and can restrict the operation commands of users through the unified operation command management center to prevent the impact of users' misoperations on online services; based on this, the embodiment of the present invention can effectively improve the security of container login.

[0076] Based on the description of the related embodiments of the above container login method, the embodiment of the present invention also proposes a container login system; as Figure 6 shown, the container login system includes a login proxy service cluster 601 and at least one Kubernetes cluster 602. The login proxy service cluster 601 includes at least one login proxy service node. A Kubernetes cluster 602 includes at least one Node node 6021, and a Node node 6021 includes a login Agent 6022. The container login system can execute Figure 1 or Figure 4 the container login method shown, that is, the container login system can run the above units:

[0077] The first login proxy service node in the login proxy service cluster 601 is used to verify the validity of the Node connection token carried in the reverse connection request when receiving the reverse connection request from any one of the login Agents 6022 in the at least one Kubernetes cluster 602, and establish a reverse tunnel with any one of the login Agents 6022 after passing the verification of the validity of the Node connection token; wherein, the first login proxy service node is any one of the login proxy service nodes in the login proxy service cluster 601, and each of the login Agents 6022 in the at least one Kubernetes cluster 602 supports establishing a reverse tunnel with each of the login proxy service nodes in the login proxy service cluster 601;

[0078] The second login proxy service node in the login proxy service cluster 601 is used to call the unified permission management module to perform container login permission verification when receiving a container login request for a container to be logged in; if the container login permission verification is successful, forward the container login request to the login Agent 6022 corresponding to the container to be logged in through the reverse tunnel corresponding to the container to be logged in, so that the login Agent 6022 corresponding to the container to be logged in executes logging in to the container to be logged in and returns a login success response to the second login proxy service node;

[0079] Wherein, the second login proxy service node is any one of the login proxy service nodes in the login proxy service cluster 601, the container to be logged in is any one of the containers in the at least one Kubernetes cluster 602, the reverse tunnel corresponding to a container is the reverse tunnel between the login Agent 6022 on the Node node 6021 where the corresponding container is located and the login proxy service cluster 601, and the login Agent 6022 corresponding to a container is the login Agent 6022 on the Node node 6021 where the corresponding container is located.

[0080] In an implementation manner, the at least one login proxy service node includes a login proxy service master node 6011 and at least one login proxy service slave node 6012, and the container login system further includes:

[0081] The login proxy service master node 6011 is used to generate at least one slave node join token, so that each of the login proxy service slave nodes 6012 in the at least one login proxy service slave node 6012 can connect to the login proxy service master node 6011 for communication after obtaining one of the at least one slave node join tokens; and / or,

[0082] The login proxy service master node 6011 is further configured to generate at least one Node connection token, so that after any one of the login Agents 6022 obtains one of the at least one Node connection tokens, the obtained Node connection token is used to send reverse connection requests to the respective login proxy service nodes.

[0083] In another implementation, a Kubernetes cluster 602 includes a management node 6023; the container login system further includes:

[0084] For any one of the at least one Kubernetes clusters 602, the management node 6023 in any one of the Kubernetes clusters 602 is configured to obtain a Node connection token from the login proxy service cluster 601, and send the obtained Node connection token to each Node node 6021 in any one of the Kubernetes clusters 602, so that the login Agent 6022 on each Node node 6021 in any one of the Kubernetes clusters 602 obtains one of the at least one Node connection tokens;

[0085] The management node 6023 in any one of the Kubernetes clusters 602 is configured to start the pod to which the login Agent 6022 on each Node node 6021 in any one of the Kubernetes clusters 602 belongs in the form of daemonset deployment, and mount the unixsocket file for communicating with the container into the pod to which the login Agent 6022 on each Node node 6021 in any one of the Kubernetes clusters 602 belongs, so that a Node node 6021 supports scheduling on the corresponding Node node 6021 through a deployed login Agent 6022.

[0086] In another implementation, any one of the login Agents 6022 is further configured to periodically report a heartbeat to the login proxy service cluster 601 to determine to maintain a connection with the login proxy service cluster 601; and / or,

[0087] Any one of the login Agents 6022 is further configured to periodically report status indication data of the Node node 6021 where the any one of the login Agents 6022 is located to the login proxy service cluster 601.

[0088] In another implementation, the container login system further includes a login proxy service front end 603;

[0089] The front-end 603 of the login proxy service is used to send the proxy service login request to the login proxy service cluster 601 when detecting a proxy service login request from a target user;

[0090] The login proxy service cluster 601 is further used to determine whether the target user is logged in after receiving the proxy service login request; if the target user is not logged in, perform identity authentication for the target user, prompt the target user that the authentication fails when the authentication fails, and make the front-end 603 of the login proxy service display a container login interface after the authentication is successful, and the container login interface supports the target user to execute the container login request.

[0091] In another implementation, the container login system further includes a unified management center 604, and the unified management center 604 includes a unified audit management center 6041;

[0092] The login proxy service cluster 601 is further used to record the login information of users through the unified audit management center 6041; and / or,

[0093] The login proxy service cluster 601 is further used to record the operation commands input by users and / or the corresponding outputs through the unified audit management center 6041;

[0094] Wherein, the unified audit management center 6041 supports data audit, and the data audit includes at least one of the following: login information audit and operation command audit.

[0095] In another implementation, the unified audit management center 6041 includes a unified cluster activity audit module;

[0096] The unified cluster activity audit module is used to obtain the status information of each cluster audit object in the at least one Kubernetes cluster 602, and a cluster audit object is any one of the following: a Node node and a container;

[0097] The unified cluster activity audit module is further used to perform activity audits on each cluster audit object respectively based on the status information of each cluster audit object to determine abnormal objects in the at least one Kubernetes cluster 602.

[0098] In another implementation, the login proxy service cluster 601 is further used to:

[0099] When receiving a target operation command input by a target user, determine whether the target operation command is an operation command allowed to be executed by the target user;

[0100] If the target operation command is a prohibited operation command, prompt the target user to prohibit the execution of the target operation command and / or guide the target user to apply for the target operation command;

[0101] If the target operation command is an allowed operation command, forward the target operation command to the login Agent 6022 corresponding to the to-be-executed container targeted by the target operation command through the reverse tunnel corresponding to the to-be-executed container, so that the login Agent 6022 corresponding to the to-be-executed container forwards the target operation command into the to-be-executed container for execution, and returns the execution result of the target operation command to the login proxy service front end 603 for display.

[0102] According to an embodiment of the present invention, it can be achieved by running a computer program (including program code) capable of executing the respective steps involved in the corresponding method shown in Figure 1 or Figure 4 on a general-purpose electronic device such as a computer including processing elements and storage elements such as a central processing unit (CPU), a random access storage medium (RAM), and a read-only storage medium (ROM), to construct a container login system as shown in Figure 6 and to implement the container login method of the embodiment of the present invention. The computer program can be recorded on a computer storage medium, for example, and loaded into the above-mentioned electronic device through the computer storage medium and run therein.

[0103] Based on the descriptions of the above method embodiments and system embodiments, an exemplary embodiment of the present invention further provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program that can be executed by the at least one processor, and when the computer program is executed by the at least one processor, it is used to cause the electronic device to execute the method according to the embodiment of the present invention.

[0104] An exemplary embodiment of the present invention further provides a non-transitory computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor of a computer, it is used to cause the computer to execute the method according to the embodiment of the present invention.

[0105] An exemplary embodiment of the present invention further provides a computer program product, including a computer program, wherein when the computer program is executed by a processor of a computer, it is used to cause the computer to execute the method according to the embodiment of the present invention.

[0106] Refer to Figure 7, a structural block diagram of an electronic device 700 that can be used as a server or a client of the present invention will now be described. It is an example of a hardware device that can be applied to various aspects of the present invention. The electronic device is intended to represent various forms of digital electronic computer devices, such as, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as, personal digital processors, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or claimed herein.

[0107] As Figure 7 shown, the electronic device 700 includes a computing unit 701, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 702 or a computer program loaded from a storage unit 708 into a random access memory (RAM) 703. In the RAM 703, various programs and data required for the operation of the electronic device 700 can also be stored. The computing unit 701, the ROM 702, and the RAM 703 are connected to each other through a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0108] Multiple components in the electronic device 700 are connected to the I / O interface 705, including: an input unit 706, an output unit 707, a storage unit 708, and a communication unit 709. The input unit 706 can be any type of device that can input information into the electronic device 700. The input unit 706 can receive input digital or character information, and generate key signal inputs related to the user settings and / or function controls of the electronic device. The output unit 707 can be any type of device that can present information, and can include but is not limited to a display, a speaker, a video / audio output terminal, a vibrator, and / or a printer. The storage unit 708 can include but is not limited to magnetic disks, optical disks. The communication unit 709 allows the electronic device 700 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks, and can include but is not limited to a modem, a network card, an infrared communication device, a wireless communication transceiver, and / or a chipset, such as a Bluetooth™ device, a WiFi device, a WiMax device, a cellular communication device, and / or the like.

[0109] The computing unit 701 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 executes the various methods and processes described above. For example, in some embodiments, the container login method can be implemented as a computer software program tangibly embodied in a machine-readable medium, such as the storage unit 708. In some embodiments, part or all of the computer program can be loaded and / or installed onto the electronic device 700 via the ROM 702 and / or the communication unit 709. In some embodiments, the computing unit 701 can be configured to execute the container login method in any other suitable way (e.g., by means of firmware).

[0110] The program code for implementing the method of the present invention can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when the program codes are executed by the processor or controller, the functions / operations specified in the flowchart and / or block diagram are implemented. The program code can be executed entirely on the machine, partially on the machine, as an independent software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0111] In the context of the present invention, a machine-readable medium can be a tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0112] As used in this invention, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and / or device (e.g., a magnetic disk, an optical disk, a memory, a programmable logic device (PLD)) used to provide machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0113] To provide for interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can also be used to provide for interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic, speech, or tactile input).

[0114] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer having a graphical user interface or a web browser through which the user can interact with an implementation of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), and the Internet.

[0115] A computer system can include a client and a server. The client and the server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

[0116] Also, it should be understood that the above-disclosed are only the preferred embodiments of the present invention, and of course cannot be used to limit the scope of the rights of the present invention. Therefore, equivalent changes made in accordance with the claims of the present invention still fall within the scope covered by the present invention.

Claims

1. A container login method, characterized in that: The container login method is applied to a container login system, wherein the container login system includes a login proxy service cluster and at least one Kubernetes cluster, wherein the login proxy service cluster includes at least one login proxy service node, a Kubernetes cluster includes at least one Node node, and a Node node includes a login Agent, wherein the method includes: When receiving a reverse connection request from any login Agent in the at least one Kubernetes cluster, the first login proxy service node in the login proxy service cluster verifies the validity of the Node connection token carried in the reverse connection request, and establishes a reverse tunnel with any login Agent after passing the Node connection token validity verification; wherein the first login proxy service node is any login proxy service node in the login proxy service cluster, and each login Agent in the at least one Kubernetes cluster supports respectively establishing a reverse tunnel with each login proxy service node in the login proxy service cluster; When receiving a container login request for the container to be logged in, the second login proxy service node in the login proxy service cluster calls the unified authority management module to perform container login authority verification; if the container login authority verification succeeds, the container login request is forwarded to the login Agent corresponding to the container to be logged in through the reverse tunnel corresponding to the container to be logged in, so that the login Agent corresponding to the container to be logged in executes the login to the container to be logged in, and returns a login success response to the second login proxy service node; Among them, the second login proxy service node is any login proxy service node in the login proxy service cluster, the container to be logged in is any container in the at least one Kubernetes cluster, the reverse tunnel corresponding to a container is the reverse tunnel between the login Agent on the Node node where the corresponding container is located and the login proxy service cluster, and the login Agent corresponding to a container is the login Agent on the Node node where the corresponding container is located.

2. The method according to claim 1, characterized in that The at least one login proxy service node includes a login proxy service master node and at least one login proxy service slave node, and the method further includes: The login proxy service master node generates at least one slave node joining token, so that each login proxy service slave node in the at least one login proxy service slave node can connect to the login proxy service master node for communication through the acquired slave node joining token after acquiring one of the at least one slave node joining tokens; and / or, The login proxy service master node generates at least one Node connection token, so that after any login Agent obtains one of the at least one Node connection token, it can send a reverse connection request to each login proxy service node through the obtained Node connection token.

3. The method according to claim 2, characterized in that A Kubernetes cluster includes a management node; the method further includes: For any Kubernetes cluster in the at least one Kubernetes cluster, the management node in the any Kubernetes cluster obtains a Node connection token from the login agent service cluster, and sends the obtained Node connection token to each Node node in the any Kubernetes cluster, so that the login Agent on each Node node in the any Kubernetes cluster obtains a Node connection token in the at least one Node connection token; The management node in any Kubernetes cluster starts the pod to which the login Agent on each Node node in any Kubernetes cluster belongs in a daemonset deployment manner, and mounts the unixsocket file that communicates with the container into the pod to which the login Agent on each Node node in any Kubernetes cluster belongs, so that a Node node supports scheduling on the corresponding Node node through a deployed login Agent.

4. The method according to any one of claims 1 to 3, characterized in that: The method further comprises: Any login agent periodically reports heartbeats to the login agent service cluster to ensure that the connection with the login agent service cluster is maintained; and / or, Any login Agent periodically reports status indication data of the Node where any login Agent is located to the login agent service cluster.

5. The method according to any one of claims 1 to 3, characterized in that: The container login system also includes a login proxy service front end; the method also includes: When the login proxy service front end detects the proxy service login request of the target user, the login proxy service front end sends the proxy service login request to the login proxy service cluster; After receiving the proxy service login request, the login proxy service cluster determines whether the target user is logged in; if the target user is not logged in, it performs identity authentication for the target user, and prompts the target user of the authentication failure when the authentication fails, and after the authentication succeeds, the login proxy service front end displays a container login interface, and the container login interface supports the target user to execute the container login request.

6. The method according to any one of claims 1 to 3, characterized in that: The container login system further includes a unified management center, the unified management center includes a unified audit management center, and the method further includes: The login proxy service cluster records the user's login information through the unified audit management center; and / or, The login proxy service cluster records the operation commands input by the user and / or the corresponding output through the unified audit management center; The unified audit management center supports data auditing, and the data auditing includes at least one of the following: login information auditing and operation command auditing.

7. The method according to claim 6, characterized in that The unified audit management center includes a unified cluster activity audit module, and the method further includes: The unified cluster activity audit module obtains status information of each cluster audit object in the at least one Kubernetes cluster, where a cluster audit object is any of the following: a Node node and a container; The unified cluster activity audit module performs activity audit on each cluster audit object based on the status information of each cluster audit object, so as to determine abnormal objects in the at least one Kubernetes cluster.

8. The method according to any one of claims 1 to 3, characterized in that: The method further comprises: When receiving the target operation command input by the target user, the login proxy service cluster determines whether the target operation command is an operation command allowed to be executed by the target user; If the target operation command is an unauthorized operation command, prompting the target user to prohibit execution of the target operation command and / or guiding the target user to apply for the target operation command; If the target operation command is an allowed operation command, the target operation command is forwarded to the login Agent corresponding to the container to be executed through the reverse tunnel corresponding to the container to be executed targeted by the target operation command, so that the login Agent corresponding to the container to be executed forwards the target operation command to the container to be executed for execution, and returns the execution result of the target operation command to the login agent service front end for display.

9. A container login system, characterized in that: The container login system includes: the login proxy service cluster and at least one Kubernetes cluster, the login proxy service cluster includes at least one login proxy service node, a Kubernetes cluster includes at least one Node node, and a Node node includes a login Agent; The first login proxy service node in the login proxy service cluster is used to verify the validity of the Node connection token carried in the reverse connection request when receiving the reverse connection request of any login Agent in the at least one Kubernetes cluster, and establish a reverse tunnel with any login Agent after passing the Node connection token validity verification; wherein the first login proxy service node is any login proxy service node in the login proxy service cluster, and each login Agent in the at least one Kubernetes cluster supports respectively establishing a reverse tunnel with each login proxy service node in the login proxy service cluster; The second login proxy service node in the login proxy service cluster is used to call the unified authority management module to perform container login authority verification when receiving a container login request for the container to be logged in; if the container login authority verification is successful, forward the container login request to the login Agent corresponding to the container to be logged in through the reverse tunnel corresponding to the container to be logged in, so that the login Agent corresponding to the container to be logged in executes the login to the container to be logged in, and returns a login success response to the second login proxy service node; Among them, the second login proxy service node is any login proxy service node in the login proxy service cluster, the container to be logged in is any container in the at least one Kubernetes cluster, the reverse tunnel corresponding to a container is the reverse tunnel between the login Agent on the Node node where the corresponding container is located and the login proxy service cluster, and the login Agent corresponding to a container is the login Agent on the Node node where the corresponding container is located.

10. The container login system according to claim 9, characterized in that: The at least one login proxy service node includes a login proxy service master node and at least one login proxy service slave node; The login proxy service master node is used to generate at least one slave node joining token, so that each login proxy service slave node in the at least one login proxy service slave node can connect to the login proxy service master node for communication through the acquired slave node joining token after acquiring one of the at least one slave node joining tokens; and / or, The login proxy service master node is also used to generate at least one Node connection token, so that after any login Agent obtains one of the at least one Node connection token, it can send a reverse connection request to each login proxy service node through the obtained Node connection token.

Images