CN110995450B

CN110995450B - Authentication and authorization method and system based on Kubernetes

Info

Publication number: CN110995450B
Application number: CN202010122452.2A
Authority: CN
Inventors: 李小飞
Original assignee: Zhongke Star Map Co ltd
Current assignee: Zhongke Star Map Co ltd
Priority date: 2020-02-27
Filing date: 2020-02-27
Publication date: 2020-06-23
Anticipated expiration: 2040-02-27
Also published as: CN110995450A

Abstract

Embodiments of the present disclosure provide kubernets-based authentication and authorization methods, systems, devices, and computer-readable storage media. The method comprises the steps that an API gateway receives a service calling request sent by a client side, and forwards the service calling request to an authentication authorization module; the authentication authorization module receives the service calling request and verifies the Access Token; if the authentication is successful, performing access control on the service calling request according to a preset strategy; if the service calling request is allowed by a preset strategy, sending an authorization indication to the API gateway; and the API gateway receives the authorization indication and forwards the service calling request to the corresponding back-end micro service. A zero-intrusion and zero-cost method is provided, so that the development cost of business service developers is reduced; through authorization rule service and domain name two-dimensional configuration, different authorities can be set for different domain names on a page, so that the safety of services is protected to the maximum extent.

Description

Authentication and authorization method and system based on Kubernetes

Technical Field

Embodiments of the present disclosure relate generally to the field of cloud computing technology and, more particularly, to kubernets-based authentication and authorization methods, systems, devices, and computer-readable storage media.

Background

In the conventional development, all functional modules are concentrated in a single application, so that most of the requirements can be met only by writing a corresponding user authorization verification function in the single application. However, with the trend of micro-services, many traditional single services are split into micro-services, that is, a plurality of light micro-services jointly implement the functions of the original single application. This poses the following problems:

1. since each microservice requires the verification of rights, it is inevitable that a large amount of identical code authorizing the verification must be written in each microservice. The logic is to pull the whole body, and once the logic of the authorization verification is changed, all the micro services are modified correspondingly to be adapted;

2. for microservices, the specific functions of microservices are the parts which should be concerned by developers, and the addition of authorization verification ensures that the developers pay more attention to the parts except the core functions, thereby reducing the development efficiency of codes;

3. since the multiple microservice functions implement the original single application function, each microservice may have multiple instances, and therefore, the developer has to do some extra work to maintain the login status of each instance of each microservice. For example, the system a is composed of a plurality of microservices such as a commodity service, an order service, a shopping cart service, and the like, and if the user logs in the commodity service of the system a, the service such as the order service, the shopping cart service, and the like should also be in a login state. In addition, even for a plurality of traditional single applications, each single application may need to share the same account password system, so as to implement the single sign-on function (for example, if a user logs in to system a, if the user opens system B, the user should be in a login state).

In order to solve the above problems, Spring Cloud Gateway is adopted in the industry to solve the problem of unified authentication and authorization at the Gateway level. The Spring Cloud Gateway is a sub-item of the open source framework Spring Cloud, and can function as a traffic ingress in the entire Spring Cloud framework. Since the Spring Cloud Gateway functions as a traffic ingress, developers filter traffic by customizing various filtering strategies through self-coding in the layer of the Spring Cloud Gateway, for example, intercepting malicious traffic, limiting malicious access, and sending different traffic re-authorization certificates to different requests. Namely, aiming at the problems 1-3, the authentication and authorization strategy is customized by self-coding at the gateway level to solve the problems. Although the Spring Cloud Gateway can solve the problem of unified authentication authorization at the Gateway level, there are many disadvantages:

1. the Spring Cloud Gateway is a sub project of Spring Cloud, so that if a user wants to use the Spring Cloud Gateway, the user must use the Spring Cloud, and the Spring Cloud is a product before Kubernets comes out, and most of the functions of the Spring Cloud are replaced by the Kubernets;

2. the Spring Cloud is invasive to the code, namely the code of the micro service needs to introduce the dependence of the Spring Cloud and corresponding development is carried out in the code, so that various characteristics provided by the Spring Cloud can be used;

3. the learning cost of the Spring Cloud is high, and each developer needs to be skilled for the Spring Cloud to use the Spring Cloud better;

4. spring Cloud is developed in Java, and therefore, the development language that limits microservices is essentially only Java. With the improvement of various programming languages, JAVA is not the first language of micro-service development;

5. for legacy non-JAVA projects or JAVA projects that do not employ Spring Cloud, a great deal of modification or even complete reimbursement is required.

Disclosure of Invention

According to an embodiment of the present disclosure, an authentication and authorization scheme based on Kubernetes is provided.

In a first aspect of the disclosure, a Kubernetes-based authentication and authorization method is provided. The method comprises the steps that an API gateway receives a service calling request sent by a client side, and forwards the service calling request to an authentication authorization module; the service calling request comprises Access Token; the authentication and authorization module receives the service calling request and verifies the Access Token; if the authentication is successful, the service calling request is considered to be legal, and access control is carried out on the service calling request according to a preset strategy; if the service calling request is allowed by a preset strategy, sending an authorization indication to the API gateway; the API gateway receives the authorization indication and forwards the service calling request to a corresponding back-end micro service; and the back-end micro service receives the service calling request and returns a response result to the client.

The above-mentioned aspects and any possible implementation manners further provide an implementation manner, where the AccessToken is obtained by applying for the authentication and authorization module by the client.

The aspect and any possible implementation manner described above further provide an implementation manner, where the service invocation request is an HTTP request, and the HTTP request header includes the Access Token as an Authorization parameter.

The above-mentioned aspects and any possible implementation manner further provide an implementation manner, where the API gateway receives a service invocation request sent by a client, and forwards the service invocation request to an authentication and authorization module; the API gateway receives a service call request sent by a client, judges whether an Authorization parameter value exists in a request header or not, intercepts the request header if no parameter value exists, and forwards the service call request to an authentication Authorization module if the Authorization parameter value exists.

The foregoing aspect and any possible implementation manner further provide an implementation manner, where the performing access control on the service invocation request according to a preset policy includes: policies configured for different microservices, and policies configured for different domain names.

The above-described aspects and any possible implementations further provide an implementation, and the method further includes: if the authentication fails, the service calling request is considered to be illegal, and a rejection indication is sent to the API gateway; and if the service calling request is not allowed by a preset strategy, sending a rejection indication to the API gateway.

The above-described aspects and any possible implementations further provide an implementation, and the method further includes: and the API gateway receives the rejection indication and informs the client that the service calling request is rejected.

In a second aspect of the disclosure, a Kubernetes-based authentication and authorization system is provided. The system comprises an API gateway and an authentication authorization module, wherein the API gateway is used for receiving a service calling request sent by a client and forwarding the service calling request to the authentication authorization module; the service calling request comprises Access Token; the system is also used for receiving an authorization instruction sent by an authentication authorization module and forwarding the service calling request to the corresponding back-end microservice; the authentication authorization module is used for receiving the service calling request and verifying the Access Token; if the authentication is successful, the service calling request is considered to be legal, and access control is carried out on the service calling request according to a preset strategy; and if the service calling request is allowed by a preset policy, sending an authorization indication to the API gateway.

In a third aspect of the disclosure, an electronic device is provided. The electronic device includes: a memory having a computer program stored thereon and a processor implementing the method as described above when executing the program.

In a fourth aspect of the present disclosure, a computer readable storage medium is provided, having stored thereon a computer program, which when executed by a processor, implements a method as in accordance with the first aspect of the present disclosure.

It should be understood that the statements herein reciting aspects are not intended to limit the critical or essential features of the embodiments of the present disclosure, nor are they intended to limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.

Drawings

The above and other features, advantages and aspects of various embodiments of the present disclosure will become more apparent by referring to the following detailed description when taken in conjunction with the accompanying drawings. In the drawings, like or similar reference characters designate like or similar elements, and wherein:

FIG. 1 illustrates a schematic diagram of an exemplary operating environment in which embodiments of the present disclosure can be implemented;

fig. 2 shows a flow diagram of a Kubernetes-based authentication authorization method according to an embodiment of the present disclosure;

fig. 3 illustrates a block diagram of a Kubernetes-based authentication and authorization system, according to an embodiment of the present disclosure;

FIG. 4 illustrates a block diagram of an exemplary electronic device capable of implementing embodiments of the present disclosure.

Detailed Description

To make the objects, technical solutions and advantages of the embodiments of the present disclosure more clear, the technical solutions of the embodiments of the present disclosure will be described clearly and completely with reference to the drawings in the embodiments of the present disclosure, and it is obvious that the described embodiments are some, but not all embodiments of the present disclosure. All other embodiments, which can be derived by a person skilled in the art from the embodiments disclosed herein without making any creative effort, shall fall within the protection scope of the present disclosure.

In addition, the term "and/or" herein is only one kind of association relationship describing an associated object, and means that there may be three kinds of relationships, for example, a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" herein generally indicates that the former and latter related objects are in an "or" relationship.

In this disclosure, (this embodiment and its advantages may be summarized simply by one paragraph, possibly not simply repeated with the claims).

Kubernetes, K8s for short, is an abbreviation used to replace the 8 characters "ubernet" with 8. Is an open source for managing containerized applications on multiple hosts in a cloud platform. Kubernets, which aims to make it simple and efficient to deploy containerized applications (powerfull), provides a mechanism for application deployment, planning, updating, and maintenance.

FIG. 1 illustrates a schematic diagram of an exemplary operating environment 100 in which embodiments of the present disclosure can be implemented; as shown in fig. 1, the runtime environment 100 includes a client 102, an authentication and authorization system 104, and a backend microservice 106; the number of the clients 102 and the backend microservices 106 may be one or more. The authentication and authorization system 104 includes: API gateway 108, authentication authorization module 110.

In some embodiments, the client 102 is an application that issues service invocation requests on behalf of a user to the backend microservices 106.

In some embodiments, the API gateway 108 may be Ambassador, which is a distributed version of open source Envoy, designed specifically for kubernets.

In some embodiments, the authentication and authorization module 110 may be an OAuth2 authentication and authorization module.

Fig. 2 is a schematic diagram illustrating an interaction method among the client 102, the API gateway 108, the authentication and authorization module 110 and the backend microservice 106 shown in fig. 1, namely, an authentication and authorization method based on kubernets;

in block 202, the client 102 accesses the authentication and authorization module 110 through the API gateway 108 to request Access Token;

in block 204, the Access authentication and authorization module 110 issues an Access Token to the client 102;

in some embodiments, the client 102 must obtain the Authorization Grant of the user to obtain the token (access token). OAuth 2.0 defines four authorization modes: authorization code mode (authorization code), reduced mode (initialization), Password mode (Resource Owner passed creatives), Client mode (Client creatives).

Taking a Password mode (Resource Owner passed creatives) as an example, after a user opens a client 102, the client 102 requires the user to give authorization; if the user agrees to give authorization to the client 102, inputting login information (or calling a Token interface to transfer user information); the client 102 sends the login information or the user information to the authentication and authorization module 110 by using the authorization, and applies for a token from the authentication and authorization module 110; after the authentication authorization module 110 authenticates the login information or user information of the client 102, if it is confirmed that the login information or user information is correct, the Access Token is issued and an interface (a general interface may include information such as user basic information, authority range, valid time, etc.) is returned to the client 102; the storage interface of the client 102 may be stored in the Session or the database, so that the Access Token is carried when the service invocation request is subsequently sent.

In block 206, the client 102 sends a service invocation request to the API gateway 108; the service calling request is an HTTP request, and the HTTP request header comprises the Access Token;

specifically, the service invocation request may be an http (hypertext transfer protocol) request, which refers to a service invocation request from the client 102 to the backend microservice 106, and when the browser sends a request to the Web server, it transmits a data block to the Web server, that is, request information, where information of the http request mainly consists of two parts: a request header (including the request method and uri protocol/version) and a request body.

In some embodiments, the Access Token requested in block 202 is added to the request header as the Authorization parameter.

At block 208, the API gateway 108 receives the service call request; forwarding the service invocation request to the authentication authorization module 110;

in some embodiments, the API gateway 108 includes a pre-filter for determining whether there is an Authorization parameter value in the request header, and if there is no Authorization parameter value, it is not necessary to route the request to the authentication and Authorization module 110, where the service call request is uniformly filtered and intercepted. If the parameter value exists, the service call request is forwarded to the authentication and authorization module 110.

In some embodiments, the authentication and authorization module 110 sets an expiration time when issuing the Access Token for the client 102; the pre-filter is further configured to determine whether the Access Token is expired, and forward the service invocation request to the authentication and authorization module 110 if the Access Token is present and not expired.

In block 210, the authentication and authorization module 110 receives the service invocation request, verifies the Access Token, if the authentication result is successful, the service invocation request is considered to be legal, and block 212 is executed; if the authentication result fails, the service invocation request is considered to be illegal, a rejection indication is sent to the API gateway 108, and block 214 is executed;

in some embodiments, the authentication and Authorization module 110 verifies whether the Access Token in the request header as the Authorization parameter is valid, and then considers that the service invocation request is valid.

In block 212, the authentication and authorization module 110 performs access control on the service call request according to a preset policy file, authorizes the service call request if the service call request is allowed by the policy, sends an authorization indication to the API gateway, and executes block 216; if not allowed by the policy, the service invocation request is denied, a denial indication is sent to the API gateway 108, and block 214 is performed.

In some embodiments, it is determined whether the client 102 has permission to access the corresponding back-end microservice 106 by authentication.

In some embodiments, a preconfigured policy of the backend microservice 106 corresponding to the service invocation request is determined; and determining whether the client 102 has the right to access the corresponding back-end micro-service 106 according to the pre-configured strategy.

In some embodiments, the policy preconfigured for authentication and authorization is generally for one dimension of the microservice, and different policies are preconfigured for different microservices; for example, for microservice Service A, it may be configured that/api/v 1/user1 requires user privileges and/api/v 1/admin privileges.

In some embodiments, the policy is added with a dimension of a domain name, for example, the microservice Service a binds two domain names of Service a.1.example.com and Service a.2.example.com, and different authentication and authorization rules may be specified for different domain names. For example, for the domain name servicea.1.example.com, the configuration/api/v 1/admin is prohibited from access, and for servicea.2.example.com, administrator privileges are required for the configuration/api/v 1/admin. Thus, for the micro Service a, when the user accesses the micro Service a through the domain name Service a.1.example. com, if trying to access the url of Service a.1.example. com/api/v1/admin, it will be intercepted by the authentication authorization module 110, and the Service call request will be rejected; and if the user tries to access url of serviceA.2.example.com/api/v1/admin and has the administrator authority, the user can normally access and authorize the Service calling request.

In some embodiments, the API gateway 108 receives a call response corresponding to the service call request returned by the authentication authorization module 110.

At block 214, the API gateway 108 notifies the client 102 that the service invocation request is denied based on the denial indication;

at block 216, the API gateway forwards the service invocation request to the corresponding backend microservice 106 according to the authorization indication;

at block 218, the back-end microservice 106 receives the service invocation request and returns a response result to the client 102.

In some embodiments, the back-end microserver 106 receives the service invocation request, performs corresponding service processing, and returns an access response corresponding to the service invocation request, which may specifically be a response resource corresponding to the service invocation request, where the access response also exists in a form of a response header + a response body.

According to the embodiment of the disclosure, the following technical effects are achieved:

1. aiming at the problem that the traditional authentication and authorization scheme needs to modify the service, authentication and authorization are carried out based on a Kubernetes platform, development is flexible, a zero-intrusion and zero-cost method is provided, and development cost of business service developers is greatly reduced.

2. The requirements of different domain names and different rules are realized through the authorization rule service and the domain name two-dimensional configuration function, and service developers can set different authorities for different domain names on a page, so that the safety of services is protected to the maximum extent.

It is noted that while for simplicity of explanation, the foregoing method embodiments have been described as a series of acts or combination of acts, it will be appreciated by those skilled in the art that the present disclosure is not limited by the order of acts, as some steps may, in accordance with the present disclosure, occur in other orders and concurrently. Further, those skilled in the art should also appreciate that the embodiments described in the specification are exemplary embodiments and that acts and modules referred to are not necessarily required by the disclosure.

The above is a description of embodiments of the method, and the embodiments of the apparatus are further described below.

Fig. 3 illustrates a block diagram of a Kubernetes-based authentication and authorization system 300 according to an embodiment of the present disclosure. As shown in fig. 3, the system 300 includes the API gateway 108 and the authentication and authorization module 110.

The API gateway 108 is configured to receive a service call request sent by a client, and forward the service call request to an authentication and authorization module; the service calling request comprises Access Token; the system is also used for receiving an authorization instruction sent by an authentication authorization module and forwarding the service calling request to the corresponding back-end microservice;

the authentication and authorization module 110 is configured to receive the service invocation request and verify the Access Token; if the authentication is successful, the service calling request is considered to be legal, and access control is carried out on the service calling request according to a preset strategy; and if the service calling request is allowed by a preset policy, sending an authorization indication to the API gateway.

It can be clearly understood by those skilled in the art that, for convenience and brevity of description, the specific working process of the described module may refer to the corresponding process in the foregoing method embodiment, and is not described herein again.

FIG. 4 shows a schematic block diagram of an electronic device 400 that may be used to implement embodiments of the present disclosure. The device 400 may be used to implement at least one of the client 102, the authentication and authorization system 104, and the backend microservice 106 of fig. 1. As shown, the device 400 includes a CPU 401 that can perform various appropriate actions and processes according to computer program instructions stored in a ROM 402 or loaded from a storage unit 408 into a RAM 403. In the RAM 403, various programs and data required for the operation of the device 400 can also be stored. The CPU 401, ROM 402, and RAM 403 are connected to each other via a bus 404. An I/O interface 405 is also connected to bus 404.

A number of components in device 400 are connected to I/O interface 405, including: an input unit 406 such as a keyboard, a mouse, or the like; an output unit 407 such as various types of displays, speakers, and the like; a storage unit 408 such as a magnetic disk, optical disk, or the like; and a communication unit 409 such as a network card, modem, wireless communication transceiver, etc. The communication unit 409 allows the device 400 to exchange information/data with other devices via a computer network, such as the internet, and/or various telecommunication networks.

The CPU 401 executes the various methods and processes described above, such as the method 200. For example, in some embodiments, the method 200 may be implemented as a computer software program tangibly embodied in a machine-readable medium, such as the storage unit 408. In some embodiments, part or all of the computer program may be loaded and/or installed onto the device 400 via the ROM 402 and/or the communication unit 409. When the computer program is loaded into RAM 403 and executed by CPU 401, one or more steps of method 200 described above may be performed. Alternatively, in other embodiments, the CPU 401 may be configured to perform the method 200 in any other suitable manner (e.g., by way of firmware).

The functions described herein above may be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), an Application Specific Standard Product (ASSP), a system on a chip (SOC), a load programmable logic device (CPLD), and the like.

Program code for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowchart and/or block diagram to be performed. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of this disclosure, a machine-readable medium may 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. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may 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 diskette, 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.

Further, while operations are depicted in a particular order, this should be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. Under certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of the disclosure. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable subcombination.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. An authentication and authorization method based on Kubernetes is characterized by comprising the following steps:

the method comprises the steps that an API gateway receives a service calling request sent by a client side, and forwards the service calling request to an authentication authorization module; the service calling request comprises Access Token;

the authentication and authorization module receives the service calling request and verifies the Access Token; if the authentication is successful, the service calling request is considered to be legal, and access control is carried out on the service calling request according to a preset strategy; if the service calling request is allowed by a preset strategy, sending an authorization indication to the API gateway;

the API gateway receives the authorization indication and forwards the service calling request to a corresponding back-end micro service;

and the back-end micro service receives the service calling request and returns a response result to the client.

2. The method of claim 1,

and the Access Token is obtained by the client applying to the authentication authorization module.

3. The method according to claim 2, wherein the service invocation request is an HTTP request, and wherein the Access Token is included in the HTTP request header as an Authorization parameter.

4. The method of claim 3, wherein the API gateway receives a service call request sent by a client, and forwarding the service call request to an authentication and authorization module comprises;

the API gateway receives a service call request sent by a client, judges whether an Authorization parameter value exists in a request header or not, intercepts the request header if no parameter value exists, and forwards the service call request to an authentication Authorization module if the Authorization parameter value exists.

5. The method of claim 1, wherein the access controlling the service invocation request according to a preset policy comprises:

policies configured for different microservices, and policies configured for different domain names.

6. The method of claim 5, further comprising:

if the authentication fails, the service calling request is considered to be illegal, and a rejection indication is sent to the API gateway;

and if the service calling request is not allowed by a preset strategy, sending a rejection indication to the API gateway.

7. The method of claim 6, further comprising:

and the API gateway receives the rejection indication and informs the client that the service calling request is rejected.

8. An authentication and authorization system based on Kubernetes is characterized by comprising an API gateway and an authentication and authorization module, wherein,

the API gateway is used for receiving a service calling request sent by a client and forwarding the service calling request to an authentication authorization module; the service calling request comprises Access Token; the system is also used for receiving an authorization instruction sent by an authentication authorization module and forwarding the service calling request to the corresponding back-end microservice;

the authentication authorization module is used for receiving the service calling request and verifying the Access Token; if the authentication is successful, the service calling request is considered to be legal, and access control is carried out on the service calling request according to a preset strategy; and if the service calling request is allowed by a preset policy, sending an authorization indication to the API gateway.

9. An electronic device comprising a memory and a processor, the memory having stored thereon a computer program, wherein the processor, when executing the program, implements the method of any of claims 1-7.

10. A computer-readable storage medium, on which a computer program is stored, which program, when being executed by a processor, carries out the method according to any one of claims 1 to 7.