CN115242528A

CN115242528A - Log-in method of Kubernets cluster management panel

Info

Publication number: CN115242528A
Application number: CN202210887781.5A
Authority: CN
Inventors: 陈南飞; 王旸; 蒋驰
Original assignee: Mingyang Industrial Technology Research Institute Shenyang Co ltd
Current assignee: Mingyang Industrial Technology Research Institute Shenyang Co ltd
Priority date: 2022-07-26
Filing date: 2022-07-26
Publication date: 2022-10-25

Abstract

The application relates to the technical field of computers, in particular to a login method of a Kubernets cluster management panel, wherein the Kubernets cluster management panel is used for managing a Kubernets cluster, and the method comprises the following steps: receiving a flow request of an RADIUS user, and acquiring a user identifier and a user password in the flow request; reading user information data in an RADIUS server through an RADIUS proxy module, and judging the dependency between the RADIUS user and the RADIUS server according to the user information data and the user identification; and if the RADIUS user belongs to the RADIUS server, allowing the Kubernets cluster to receive flow data of the RADIUS user so as to enable the RADIUS user to log in the Kubernets cluster management panel through a service account corresponding to the user identification. The technical scheme provided by the application can expand the login mode of the Kubernets cluster management panel to a certain extent.

Description

Log-in method of Kubernetes cluster management panel

Technical Field

The application relates to the technical field of computers, in particular to a login method of a Kubernetes cluster management panel.

Background

As technology in the field of containers continues to mature, more and more traditional monomer applications are being retrofitted to container deployments, and kuberetes has received more and more attention as an outstanding step in the field of container deployment. Among them, the authentication and authorization function for Kubernetes is a very important item. In the prior art, a temporary Token or a certificate Kubeconfig is usually adopted to realize the kubernets cluster management panel login, but the existing login method has many problems, for example, the login credential is not easy to remember and carry, the login credential is easy to lose, and the user information potential safety hazard is easily caused.

Therefore, those skilled in the art urgently need a login method for a kubernets cluster management panel, so as to expand the login mode of the kubernets cluster management panel.

Disclosure of Invention

Embodiments of the present application provide a login method for a kubernets cluster management panel, and further, a login method for a kubernets cluster management panel can be extended to at least some extent.

Other features and advantages of the present application will be apparent from the following detailed description, or may be learned by practice of the application.

According to an aspect of an embodiment of the present application, there is provided a login method for a kubernets cluster management panel, where the kubernets cluster management panel is configured to manage a kubernets cluster, and the method includes: receiving a flow request of an RADIUS user, and acquiring a user identifier and a user password in the flow request; reading user information data in an RADIUS server through an RADIUS proxy module, and judging the dependency between the RADIUS user and the RADIUS server according to the user information data and the user identification; and if the RADIUS user belongs to the RADIUS server, allowing the Kubernet cluster to receive flow data of the RADIUS user so that the RADIUS user logs in to the Kubernet cluster management panel through a service account corresponding to the user identification.

In some embodiments of the present application, prior to receiving a login request of a RADIUS user, the method further comprises: and adding a Restful API login interface in the Kubernetes cluster, wherein the Restful API login interface is used for receiving a login request of a RADIUS user.

In some embodiments of the application, before reading the user information data in the RADIUS server by the RADIUS proxy module, the method further comprises: adding a RADIUS proxy module in the Kubernetes cluster; the RADIUS proxy module is configured such that the RADIUS proxy module is connected to a RADIUS server.

In some embodiments of the present application, based on the foregoing solution, configuring the RADIUS proxy module includes: and configuring the RADIUS proxy module according to the RADIUS server address, a communication protocol between the RADIUS proxy module and the RADIUS server and a communication port between the RADIUS proxy module and the RADIUS server.

In some embodiments of the present application, the determining, according to the user information data and the user identifier, the dependency between the RADIUS user and the RADIUS server includes: and inquiring the user information data, and if the user information data has the user identification which is the same as the user identification, judging that the RADIUS user belongs to the RADIUS server.

In some embodiments of the present application, the determining, according to the user information data and the user identifier, that the RADIUS user is subordinate to the RADIUS server further includes: and inquiring the user information data, and if the RADIUS user is judged not to belong to the RADIUS server, sending connection failure information to the RADIUS user.

In some embodiments of the application, the allowing the kubernets cluster to receive traffic data of the RADIUS user so that the RADIUS user logs in to the kubernets cluster management panel through a service account corresponding to the user identifier includes: allowing the Kubernets cluster to receive flow data of the RADIUS user and verifying the matching degree of the user identification and the user password; and if the user identification is matched with the user password, allowing the RADIUS user to log in the Kubernets cluster management panel through a service account corresponding to the user identification.

In some embodiments of the present application, based on the foregoing scheme, after verifying the matching degree between the user identifier and the user password, the method further includes: and if the user identification is not matched with the user password, the Kubernets cluster stops receiving the flow data of the RADIUS user and sends login failure information to the RADIUS user.

In some embodiments of the present application, based on the foregoing solution, before allowing the RADIUS user to log in to the kubernets cluster management panel through the service account corresponding to the user identifier, the method further includes: and creating a service account corresponding to the user identification in the Kubernets cluster.

In some embodiments of the present application, based on the foregoing solution, after creating a service account corresponding to the user identifier in the kubernets cluster, the method further includes: and in the Kubernets cluster, granting at least one access right aiming at the resources of the Kubernets cluster to the service account corresponding to the user identification.

Based on the scheme, the application has at least the following advantages or progresses:

in the technical solutions provided in some embodiments of the present application, a flow request of a RADIUS user is received, and a dependency between the RADIUS user and the RADIUS server is determined; and if the RADIUS user belongs to the RADIUS server, allowing the Kubernets cluster to receive flow data of the RADIUS user so as to enable the RADIUS user to log in the Kubernets cluster management panel through a service account corresponding to the user identification. The method and the device have the advantages that the login mode of the Kubernets cluster is expanded to a certain extent, the information safety hidden danger is reduced, the RADIUS user can be directly accessed to the Kubernets cluster, and the convenience degree of the RADIUS user in using the Kubernets cluster is effectively improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application.

It is obvious that the drawings in the following description are only some embodiments of the application, and that for a person skilled in the art, other drawings can be derived from them without inventive effort.

In the drawings:

FIG. 1 illustrates a flow diagram of a method for logon of a Kubernetes cluster management panel according to one embodiment of the present application;

FIG. 2 illustrates a flow diagram of a method of logon for a Kubernetes cluster management panel according to one embodiment of the present application;

FIG. 3 illustrates a flow diagram of a RADIUS authenticator determining the validity of a login request according to one embodiment of the present application;

FIG. 4 shows a schematic diagram of a login device for a Kubernets cluster management panel according to an embodiment of the present application;

FIG. 5 illustrates a schematic structural diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present application.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the application. One skilled in the relevant art will recognize, however, that the embodiments of the present application can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known methods, devices, implementations, or operations have not been shown or described in detail to avoid obscuring aspects of the application.

The block diagrams shown in the figures are functional entities only and do not necessarily correspond to physically separate entities. I.e. these functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor means and/or microcontroller means.

The flowcharts shown in the figures are illustrative only and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.

It should be noted that: reference herein to "a plurality" means two or more. "and/or" describe the association relationship of the associated objects, meaning that there may be three relationships, e.g., A and/or B may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.

It should be noted that the embodiments proposed in the present application can be used in a cloud scenario, such as cloud computing, which is a computing mode that distributes computing tasks over a resource pool formed by a large number of computers, so that various application systems can obtain computing power, storage space, and information services as needed. The network that provides the resources is referred to as the "cloud". Resources in the cloud can be infinitely expanded to users, and can be acquired at any time, used as required and expanded at any time. The cloud computing resource pool mainly comprises computing equipment (which is a virtualization machine and comprises an operating system), storage equipment and network equipment.

It should be noted that the present application has technical contents related to a visualization management panel of a Dashboard, i.e., kubernets cluster. A user may deploy a container application to a kubernets cluster using a Dashboard, may debug the container application, may manage the cluster itself and its attached resources, may obtain overview information of applications running in the cluster using the Dashboard, and may create or modify kubernets resources (e.g., deployment, job, daemon, etc.).

It should be noted that the present application also relates to the technical content of RADIUS, RADIUS: remote Authentication Dial In User Service, the Remote User Dial Authentication System is defined by RFC2865, RFC2866, and is the most widely applied AAA protocol. AAA is a management framework and, therefore, can be implemented with a variety of protocols. In practice, one most commonly implements AAA using Remote Access Dial In User Service (RADIUS). RADIUS is a protocol of C/S structure, the client of the RADIUS is an NAS (Net Access Server) Server originally, and any computer running RADIUS client software can become a client of RADIUS. The RADIUS protocol authentication mechanism is flexible, and can adopt PAP, CHAP or Unix login authentication and other modes. RADIUS is an extensible protocol, and all work it does is based on the Attribute-Length-Value vector. RADIUS also supports vendor-specific attributes.

The implementation details of the technical solution of the embodiment of the present application are set forth in detail below:

please refer to fig. 1.

Fig. 1 shows a flowchart of a login method of a kubernets cluster management panel according to an embodiment of the present application, and as shown in fig. 1, the method may include steps S101-S103:

step S101, receiving a flow request of a RADIUS user, and acquiring a user identifier and a user password in the flow request.

Step S102, reading user information data in the RADIUS server through the RADIUS proxy module, and judging the dependency of the RADIUS user and the RADIUS server according to the user information data and the user identification.

Step S103, if the RADIUS user belongs to the RADIUS server, allowing the Kubernet cluster to receive flow data of the RADIUS user, so that the RADIUS user logs in to the Kubernet cluster management panel through a service account corresponding to the user identification.

In the application, the dependency between the RADIUS user and the RADIUS server is judged by receiving a flow request of the RADIUS user; and if the RADIUS user belongs to the RADIUS server, allowing the Kubernet cluster to receive flow data of the RADIUS user so that the RADIUS user logs in to the Kubernet cluster management panel through a service account corresponding to the user identification. The method and the device have the advantages that the login mode of the Kubernets cluster is expanded to a certain extent, the information safety hidden danger is reduced, the RADIUS user can be directly accessed to the Kubernets cluster, and the convenience degree of the RADIUS user in using the Kubernets cluster is effectively improved.

In the application, before receiving a flow request of a RADIUS user, a Restful API login interface may be added to the kubernets cluster, where the Restful API login interface is used to receive a login request of the RADIUS user.

In this application, when a RADIUS User logs in a Dashboard using the Restful API login interface, it is necessary to provide a unique identifier of the User in RADIUS, such as UID (User ID), DN (disconnected Name), etc., or other information that can uniquely identify the User in RADIUS. Meanwhile, when a RADIUS user logs in to the Dashboard by using the Restful API login interface, the login password of the user in RADIUS must be provided.

In this application, the Restful API login interface may provide a Restful API access endpoint for RADIUS users and persist RADIUS user data into the etcd server of the Kubernetes cluster.

Please refer to fig. 2.

Fig. 2 shows a flowchart of a login method of a kubernets cluster management panel according to an embodiment of the present application, and before reading user information data in a RADIUS server through a RADIUS proxy module, as shown in fig. 2, the method may include steps S201 to S202:

step S201, adding a RADIUS proxy module in the Kubernetes cluster.

Step S202, configuring the RADIUS proxy module so that the RADIUS proxy module is connected to a RADIUS server.

In the present application, the RADIUS proxy module may be configured according to the RADIUS server address, a communication protocol between the RADIUS proxy module and the RADIUS server, and a communication port between the RADIUS proxy module and the RADIUS server.

In the application, the configured RADIUS proxy module can be used for accessing the RADIUS server, and the user identifier and the user password corresponding to each user in the RADIUS server are read through the administrator user identifier and the user password corresponding to the RADIUS server, so that comparison data can be provided for the subsequent verification of the legality of the login request.

In the application, the RADIUS proxy module may also maintain the user identifier of each RADIUS user, and automatically create a corresponding service account for each user: the RADIUS proxy module periodically (e.g., a little in the morning each day) or manually triggers it to obtain the subscriber identities of all users from the RADIUS server. Then, for each RADIUS user, according to the user identifier of the user, a Service Account (Service Account) bound with the user is created in the kubernets cluster.

For example, the name of the service account may be specified in metadata. When the RADIUS proxy module maintains the unique user identifiers of all users in RADIUS, if service accounts bound with the RADIUS user one by one exist in the Kubernets cluster for each RADIUS user, the service account does not need to be created for the user again. Meanwhile, if a service account bound to a RADIUS user one by one exists in the kubernets cluster, but the RADIUS user is deleted in the RADIUS server, the service account also needs to be deleted in the kubernets cluster.

In this application, the RADIUS proxy module may also determine, according to a user identifier carried in the login interface, whether the user is an effective RADIUS user: firstly, the RADIUS proxy module searches whether a service account which is bound with a user one by one exists in a Kubernetes cluster according to the user identification of a RADIUS user. If so, the user is a valid RADIUS user. Secondly, if service accounts which are bound with the users one by one do not exist in the Kubernets cluster, the RADIUS proxy module sends a request to the RADIUS server and inquires whether the users exist in the RADIUS server or not. If the query result indicates that the user exists in the RADIUS server, the user is a valid RADIUS user, and a service account bound with the user is created for the user in the Kubernets cluster. Otherwise, the user is an illegal RADIUS user.

In this application, the method for determining the dependency between the RADIUS user and the RADIUS server according to the user information data and the user identifier and according to the user information data and the user identifier may include: and querying the user information data, and if the user information data has a user identifier which is the same as the user identifier, judging that the RADIUS user belongs to the RADIUS server.

In the application, based on the authentication principle of the RADIUS server, whether a current login user is a user in the RADIUS server or not can be judged according to the user identifier, the RADIUS server is accessed through the RADIUS proxy module, and whether the user with the same user identifier exists in the RADIUS server or not is searched. And if the user identification which is the same as the user identification exists in the user information data in the RADIUS server, judging that the RADIUS user belongs to the RADIUS server. It is now possible to start receiving data and starting charging for the currently logged-on user, but still not allowing the currently logged-on user to log on to the kubernets cluster management panel. The matching degree of the user identification and the user password can be verified; and if the user identification is matched with the user password, allowing the RADIUS user to log in the Kubernets cluster management panel through a service account corresponding to the user identification.

In the application, a RADIUS authenticator can be added in the kubernets cluster, and the RADIUS authenticator can judge the legality of the login request according to the user information data, the user identifier and the user password, so that a RADIUS user can log in the kubernets Dashboard according to the user identifier and the user password.

Please refer to fig. 3.

Fig. 3 shows a flowchart of the RADIUS authenticator for determining validity of the login request according to an embodiment of the present application, and as shown in fig. 3, the determining process may include the following steps:

step S301 is executed first: and judging the dependency of the RADIUS user and the RADIUS server by comparing whether the user identifier exists in the user information data or not according to the user information data and the user identifier.

If the RADIUS user is judged to belong to the RADIUS server, step S302 is executed: and allowing the Kubernetes cluster to receive the flow data of the RADIUS user and verifying the matching degree of the user identification and the user password.

If the RADIUS user is not judged to belong to the RADIUS server, step S303 is executed: and not receiving the flow data of the RADIUS user, and sending the information of connection failure to the RADIUS user.

After step S302, if the user id and the user password match, step S304 is performed: and allowing the RADIUS user to log in the Kubernets cluster management panel through the service account corresponding to the user identification.

After step S302 is executed, if the user identifier and the user password do not match, step S305 is executed: and the Kubernetes cluster stops receiving the flow data of the RADIUS user and sends login failure information to the RADIUS user.

In this application, in addition to automatically creating a service account through a RADIUS proxy module, before allowing the RADIUS user to log in to the kubernets cluster management panel through the service account corresponding to the user identifier, a service account corresponding to the user identifier may be created in the kubernets cluster, and at least one access right for a resource of the kubernets cluster is granted to the service account corresponding to the user identifier.

In the application, a RADIUS authorization module may be added in the kubernets cluster, and is used to grant an access right of a kubernets resource to a RADIUS user. The workflow of the RADIUS authorization module is as follows.

(1) According to the actual authorization requirement, clusterRole (or Role) objects are created for RADIUS users, and the access rights of Kubernetes resources are defined through the objects.

(2) The method comprises the steps of creating a ClusterRolebinding (or Rolebinding) object for a RADIUS user, associating a service account bound with the RADIUS user with the ClusterRole (or Role) object, thereby realizing the resource access right defined by the ClusterRole (or Role) object, granting the service account bound with the RADIUS user and further realizing the authorization of the RADIUS user.

For example, in one embodiment of the present application, a RADIUS administrator user may default to granting read and write rights to all resources within a kubernets cluster. Assume that the service account bound to the RADIUS administrator user in the Kubernets cluster is admin, belonging to the RADIUS-system namespace.

First, a ClusterRole object needs to be created for a RADIUS administrator user, as described below.

Second, a ClusterRolebinding object needs to be created for the RADIUS administrator user, as described below.

By creating the two resource objects, the read-write authority of all resources in the Kubernets cluster can be granted to the RADIUS administrator user.

An apparatus embodiment of the present application will be described with reference to the accompanying drawings.

Please refer to fig. 4.

Fig. 4 shows a schematic diagram of a login device of a kubernets cluster management panel according to an embodiment of the present application, the device 400 may include: a receiving unit 401, a reading unit 402, and a logging unit 403.

The specific configuration of the login device of the kubernets cluster management panel may be as follows: a receiving unit 401, configured to receive a traffic request of a RADIUS user, and obtain a user identifier and a user password in the traffic request; a reading unit 402, configured to read user information data in a RADIUS server through a RADIUS proxy module, and determine a dependency between the RADIUS user and the RADIUS server according to the user information data and the user identifier; a login unit 403, configured to allow the kubernet cluster to receive traffic data of the RADIUS user if the RADIUS user belongs to the RADIUS server, so that the RADIUS user logs in to the kubernet cluster management panel through a service account corresponding to the user identifier.

Please refer to fig. 5.

FIG. 5 illustrates a schematic structural diagram of a computer system suitable for use to implement the electronic device of the embodiments of the subject application.

It should be noted that the computer system 500 of the electronic device shown in fig. 5 is only an example, and should not bring any limitation to the functions and the application scope of the embodiments of the present application.

As shown in fig. 5, the computer system 500 includes a Central Processing Unit (CPU) 501, which can perform various suitable actions and processes, such as executing the method described in the above embodiments, according to a program stored in a Read-Only Memory (ROM) 502 or a program loaded from a storage portion 508 into a Random Access Memory (RAM) 503. In the RAM 503, various programs and data necessary for system operation are also stored. The CPU 501, ROM 502, and RAM 503 are connected to each other via a bus 504. An Input/Output (I/O) interface 505 is also connected to bus 504.

The following components are connected to the I/O interface 505: an input portion 506 including a keyboard, a mouse, and the like; an output section 507 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, a speaker, and the like; a storage portion 508 including a hard disk and the like; and a communication section 509 including a Network interface card such as a LAN (Local Area Network) card, a modem, or the like. The communication section 509 performs communication processing via a network such as the internet. A drive 510 is also connected to the I/O interface 505 as needed. A removable medium 511 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 510 as necessary, so that a computer program read out therefrom is mounted into the storage section 508 as necessary.

In particular, according to embodiments of the present application, the processes described above with reference to the flow diagrams may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer-readable medium, the computer program comprising program code for performing the method illustrated by the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 509, and/or installed from the removable medium 511. The computer program executes various functions defined in the system of the present application when executed by a Central Processing Unit (CPU) 501.

It should be noted that the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a Read-Only Memory (ROM), an Erasable Programmable Read-Only Memory (EPROM), a 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. In the present application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. Each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units described in the embodiments of the present application may be implemented by software, or may be implemented by hardware, and the described units may also be disposed in a processor. Wherein the names of the elements do not in some way constitute a limitation on the elements themselves.

As another aspect, the present application also provides a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions to make the computer device execute the login method of the kubernets cluster management panel described in the above embodiments.

As another aspect, the present application also provides a computer-readable medium, which may be contained in the electronic device described in the above embodiments; or may exist separately without being assembled into the electronic device. The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to implement the method for logging in a kubernets cluster management panel described in the above embodiments.

It should be noted that although in the above detailed description several modules or units of the device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit, according to embodiments of the application. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units.

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, and may also be implemented by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the embodiments of the present application.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains.

It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. A login method of a Kubernets cluster management panel, wherein the Kubernets cluster management panel is used for managing a Kubernets cluster, and the method comprises the following steps:

receiving a flow request of an RADIUS user, and acquiring a user identifier and a user password in the flow request;

reading user information data in an RADIUS server through an RADIUS proxy module, and judging the dependency between the RADIUS user and the RADIUS server according to the user information data and the user identification;

and if the RADIUS user belongs to the RADIUS server, allowing the Kubernet cluster to receive flow data of the RADIUS user so that the RADIUS user logs in to the Kubernet cluster management panel through a service account corresponding to the user identification.

2. The method of claim 1, wherein prior to receiving a traffic request for a RADIUS subscriber, the method further comprises:

and adding a Restful API login interface in the Kubernetes cluster, wherein the Restful API login interface is used for receiving a flow request of a RADIUS user.

3. The method of claim 1, wherein prior to reading user information data in the RADIUS server via the RADIUS proxy module, the method further comprises:

adding a RADIUS proxy module in the Kubernetes cluster;

the RADIUS proxy module is configured such that the RADIUS proxy module is connected to a RADIUS server.

4. The method of claim 3, wherein configuring the RADIUS proxy module comprises:

and configuring the RADIUS proxy module according to the RADIUS server address, a communication protocol between the RADIUS proxy module and the RADIUS server and a communication port between the RADIUS proxy module and the RADIUS server.

5. The method of claim 1, wherein said determining the RADIUS user's dependency from the RADIUS server based on the user information data and the user identification comprises:

and querying the user information data, and if the user information data has a user identifier which is the same as the user identifier, judging that the RADIUS user belongs to the RADIUS server.

6. The method of claim 1, wherein said determining the RADIUS user's dependency from the RADIUS server based on the user information data and the user identification further comprises:

and inquiring the user information data, and if the RADIUS user is judged not to belong to the RADIUS server, sending connection failure information to the RADIUS user.

7. The method of claim 1, wherein the allowing the kubernets cluster to receive the traffic data of the RADIUS user so that the RADIUS user logs in to the kubernets cluster management panel through a service account corresponding to the user identifier comprises:

allowing the Kubernetes cluster to receive flow data of the RADIUS user and verifying the matching degree of the user identification and the user password;

and if the user identification is matched with the user password, allowing the RADIUS user to log in the Kubernetes cluster management panel through a service account corresponding to the user identification.

8. The method of claim 7, wherein after verifying the degree of match between the user identification and the user password, the method further comprises:

and if the user identification is not matched with the user password, the Kubernets cluster stops receiving the flow data of the RADIUS user and sends login failure information to the RADIUS user.

9. The method of claim 7, wherein prior to allowing the RADIUS user to log into the Kubernets cluster management panel through the service account corresponding to the user identification, the method further comprises:

and creating a service account corresponding to the user identification in the Kubernets cluster.

10. The method of claim 9, wherein after creating the service account corresponding to the user identity in the kubernets cluster, the method further comprises:

and in the Kubernets cluster, granting at least one access right aiming at the resources of the Kubernets cluster to the service account corresponding to the user identification.