Microservice Access Management Method, System, Electronic Device and Readable Storage Medium

Abstract

The present application discloses a microservice access management method, system, electronic device and readable storage medium, relating to the field of microservices. The method includes: receiving a microservice access request from a client; determining the business service requested by the client and the source address corresponding to the client according to the microservice access request; querying whether there is an access policy for the source address in the business service under the API authorization service; if so, authorizing the client to access the business service according to the access policy; if not, rejecting the client's access to the business service. The present application sets access policies corresponding to different business services and source addresses, and only when the source address exists in the business service of the API authorization service, the client is allowed to access according to the access policy. The present application determines different levels of access permissions for different clients through the access policy, effectively improving the security of microservice business service access.

Description

Technical Field

[0001] The present invention relates to the field of microservice systems, and particularly to a microservice access management method, system, electronic device and readable storage medium. Background Art

[0002] The microservice architecture aims to decompose the complete functions into discrete services, thereby reducing the coupling of the system and providing more flexible service support.

[0003] In the microservice architecture, for the control of microservice access, the existing setting scheme is based on the request success rate. Specifically, first obtain the request success rate of the access requests currently sent to each microservice system, and adjust the request threshold of each microservice system according to the request success rate according to a preset strategy. The request threshold is the maximum number of access requests allowed to be sent to the microservice system within a preset time period, and the access to each microservice system is controlled by this request threshold. This scheme can reduce the avalanche effect under microservice system failures, thus ensuring the stable operation of the system to the greatest extent, but it cannot restrict the request sender and cannot effectively manage the usage rights of microservices.

[0004] Therefore, how to provide a solution to solve the above technical problems is a problem that those skilled in the art need to solve currently. Summary of the Invention

[0005] In view of this, the purpose of the present invention is to provide a microservice access management method, system, electronic device and readable storage medium that can provide services more flexibly. The specific scheme is as follows:

[0006] A microservice access management method includes:

[0007] Receiving a microservice access request from a client;

[0008] Determining the business service requested by the client and the source address corresponding to the client according to the microservice access request;

[0009] Querying whether there is an access policy for the source address in the business service under the API authorization service;

[0010] If so, authorizing the client to access the business service according to the access policy;

[0011] If not, rejecting the client's access to the business service.

[0012] Preferably, before receiving the microservice access request from the client, it further includes:

[0013] Receiving a configuration instruction;

[0014] According to the configuration instruction, the corresponding business service, the source address and the access policy are configured in the API authorization service.

[0015] Preferably, the process of receiving the configuration instruction includes:

[0016] The configuration instruction corresponding to the API authorization service of the site is received through the gateway.

[0017] Preferably, the process of configuring the corresponding business service, the source address and the access policy in the API authorization service according to the configuration instruction includes:

[0018] According to the configuration instructions, an access policy object with a preset validity period is created on istio and K8S, and the corresponding business service, source address and access policy of the access policy object are configured in the API authorization service.

[0019] Preferably, the microservice access management method further includes:

[0020] When the creation time of any of the access policy objects exceeds the preset validity period, the access policy object is deleted.

[0021] Preferably, the microservice access request is a token access request carried in an HTTP message header.

[0022] Preferably, the access strategy includes: microservice level, and / or service interface, and / or service calling method.

[0023] Accordingly, this application also discloses a microservice access management system, including:

[0024] Receiving module, used to receive microservice access requests from clients;

[0025] An analysis module is configured to determine the business service requested by the client and the source address corresponding to the client according to the microservice access request;

[0026] A query module is used to query whether there is an access policy for the source address in the business service under the API authorization service; if so, authorize the client to access the business service according to the access policy; if not, deny the client access to the business service.

[0027] Accordingly, the present application also discloses an electronic device, comprising:

[0028] memory for storing computer programs;

[0029] A processor for implementing the steps of the microservice access management method as described in any one of the above when executing the computer program.

[0030] Correspondingly, the present application also discloses a readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of the microservice access management method as described in any one of the above are implemented.

[0031] The present application discloses a microservice access management method, including: receiving a microservice access request from a client; determining the business service requested by the client and the source address corresponding to the client according to the microservice access request; querying whether there is an access policy for the source address in the business service under the API authorization service; if so, authorizing the client to access the business service according to the access policy; if not, rejecting the client's access to the business service. The present application sets access policies corresponding to different business services and source addresses, and only when the source address exists in the business service of the API authorization service, the client is allowed to access according to the access policy. The present application determines different levels of access permissions for different clients through the access policy, effectively improving the security of microservice business service access. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only the embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained according to the provided drawings without creative efforts.

[0033] Figure 1 It is a flowchart of the steps of a microservice access management method in an embodiment of the present invention;

[0034] Figure 2 It is a structural distribution diagram of a microservice access management system in an embodiment of the present invention;

[0035] Figure 3 It is a structural distribution diagram of an electronic device in an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0036] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present invention.

[0037] In a microservices architecture, the existing control scheme for microservice access is based on the request success rate. This scheme can reduce the avalanche effect caused by microservice system failures, thereby ensuring the stable operation of the system to the greatest extent. However, it cannot restrict the request sender and cannot effectively manage the use permissions of microservices.

[0038] This application sets access policies corresponding to different business services and source addresses. Only when the source address exists in the business service of the API authorization service will the client be allowed access according to the access policy. This application determines the different levels of access rights for different clients through access policies, effectively improving the security of microservice business service access.

[0039] The embodiment of the present invention discloses a microservice access management method, see Figure 1 Shown, including:

[0040] Step S1: Receive the microservice access request from the client;

[0041] Step S2: Determine the business service requested by the client and the source address corresponding to the client based on the microservice access request;

[0042] Step S3: Check whether there is an access policy for the source address in the business service under the API authorization service;

[0043] Step S4: If yes, authorize the client to access the business service according to the access policy;

[0044] Step S5: If not, deny the client access to the business service.

[0045] It can be understood that in this embodiment, after receiving the client's microservice access request, the business service requested by the client and the source address corresponding to the client can be determined according to the content of the microservice access request, and the access policy of the client's source address is queried under the API (Application Programming Interface) authorization service, that is, whether the source address of the client has the access right to use the business service. If so, the client is authorized according to the access policy pre-existing in the API authorization service, and the client is allowed to access the business service according to the access policy. If not, it proves that the current client is not authorized for the business service, and the client's access to the business service is denied.

[0046] It is understandable that the microservice access request is specifically an access request in the form of a token. For the same microservice access request, there is only one access policy corresponding to the API authorization service. However, the same client can use different token access requests to obtain different access policies. Different token access requests can correspond to different business services or different access policies for the same business service. Whether a specific token access request can be authorized depends on whether there is a corresponding access policy preset in the API authorization service.

[0047] Further, it can be an optional token access request carried in the HTTP (Hyper Text Transfer Protocol) header. It is understandable that HTTP is an application layer protocol applied to distributed, collaborative, and hypermedia information systems and is the most widely used network transmission protocol on the Internet. In fact, a standard for requests and responses between the client and the server is established through HTTP.

[0048] It is understandable that in this embodiment, different access policies are set for different source addresses and different business services. The dimensional descriptions of the access policies include, but are not limited to: microservice level, and / or service interface, and / or service call method. Among them, the microservice level includes the application level, the service interface includes the service interfaces allowed to be provided to the current client among the multiple available service interfaces of a certain business service, and the service call method includes various method functions for calling services. In addition to the limitations on the access policies in these dimensions, different conditions can also be set in other dimensions as fine-grained management parameters for different source addresses and different business services, such as data volume limitations, expiration date limitations, response speed or time period limitations, etc., to provide users with diversified microservice access control.

[0049] The embodiment of the present application discloses a microservice access management method, including: receiving a microservice access request from a client; determining the business service requested by the client and the source address corresponding to the client according to the microservice access request; querying whether there is an access policy for the source address in the business service under the API authorization service; if so, authorizing the client to access the business service according to the access policy; if not, rejecting the client's access to the business service. The embodiment of the present application sets access policies corresponding to different business services and source addresses. Only when the source address exists in the business service of the API authorization service, the client is allowed to access according to the access policy. The present application determines different levels of access permissions for different clients through access policies, effectively improving the security of microservice business service access.

[0050] An embodiment of the present invention discloses a specific microservice access management method. Compared with the previous embodiment, this embodiment further explains and optimizes the technical solution. Specifically, this embodiment further explains how to configure access policies.

[0051] Further, before step S1 of receiving a microservice access request from a client, it further includes:

[0052] Receiving a configuration instruction;

[0053] According to the configuration instruction, configure corresponding business services, source addresses, and access policies in the API authorization service.

[0054] It can be understood that the configuration instruction is generally generated by a management node in the network. The management node is provided with a configuration port, and the user transmits configuration information to the management node through this configuration port. After receiving the configuration information, the management node will generate a configuration instruction and send it to the relevant gateway through the network. The configuration port includes but is not limited to human-computer interaction interfaces such as a UI interface. The specific type is not limited in this embodiment and all belong to the protection scope of this embodiment.

[0055] In some specific embodiments, the process of receiving a configuration instruction includes:

[0056] Receiving, through a gateway, a configuration instruction corresponding to the API authorization service of this site.

[0057] It can be understood that when the gateway service receives a configuration instruction, it will forward the configuration instruction according to the access address of the configuration instruction and forward the configuration instruction to the corresponding site.

[0058] In some specific embodiments, the process of configuring corresponding business services, source addresses, and access policies in the API authorization service according to the configuration instruction includes:

[0059] According to the configuration instruction, create an access policy object with a preset expiration period on istio and K8S, and configure the corresponding business services, source addresses, and access policies of the access policy object in the API authorization service.

[0060] Further, the microservice access management method further includes:

[0061] When the creation duration of any access policy object exceeds the preset expiration period, delete the access policy object.

[0062] It is understandable that the action of deleting the expired access policy object continuously occurs during the execution of steps S1 - S4. The preset expiration date is determined according to the configuration instruction when the access policy is created. They both belong to the configuration parameters. After the creation time of the access policy object exceeds the preset expiration date, the access policy object and related access policies can be directly deleted, or the access policy object can also be set to an invalid state. When the next configuration instruction is for this access policy object, it can be restored from invalid to valid state.

[0063] An embodiment of the present invention discloses a specific microservice access management method. Compared with the previous embodiment, this embodiment further explains and optimizes the technical solution. Specifically, taking the microservice access management of client 1 and client 2 to business service 1 and business service 2 as an example:

[0064] Pre - configure the corresponding business services, source addresses, and access policies in the API authorization service according to the configuration instruction. For example, when configuring the access policy of client 1 for business service 1, receive the configuration instruction for client 1. The information in the configuration instruction includes the source address IP1 of client 1, the token access validity period, i.e., the preset expiration date, and the access policy. The access policy includes but is not limited to specifying the business service interface and the call method. The configuration information first reaches the gateway service from the management node, and the gateway service forwards it to the API authorization service according to the address of the business service to be accessed in the configuration instruction. After receiving the configuration instruction, the API authorization service creates the access policy corresponding to the source address of client 1 on business service 1 and creates access objects on istio and K8S to control the access of client 1 to business service 1. Then, when client 1 accesses business service 1, client 1 sends a microservice access request, parses the token of the microservice access request. If the token is within the current validity period, the source address IP1 is within the authorization range of business service 1, and the service interface and call method also conform to the preset access policy, then client 1 can be authorized to access the service interface of business service 1.

[0065] However, assume that the access policy of business service 1 for client 2 and the access policy of business service 2 for client 1 are not configured during the pre - configuration. Then, when receiving the microservice access request of client 2 for business service 1, the corresponding access policy cannot be queried under the API authorization service, and the access of client 2 to business service 1 is refused. Similarly, when receiving the microservice access request of client 1 for business service 2, the corresponding access policy cannot be queried under the API authorization service, and the access of client 1 to business service 2 is refused.

[0066] Correspondingly, an embodiment of the present application also discloses a microservice access management system. See Figure 2 as shown, including:

[0067] A receiving module 01 for receiving microservice access requests from clients;

[0068] An analysis module 02 for determining the business service requested by the client and the source address corresponding to the client according to the microservice access request;

[0069] A query module 03 for querying whether there is an access policy for the source address in the business service under the API authorization service; if so, authorizing the client to access the business service according to the access policy; if not, rejecting the client's access to the business service.

[0070] In the embodiments of the present application, access policies corresponding to different business services and source addresses are set. Only when the source address exists in the business service of the API authorization service, the client is allowed to access according to the access policy. The present application determines different levels of access permissions for different clients through access policies, effectively improving the security of microservice business service access.

[0071] In some specific embodiments, before the receiving module 01 receives the microservice access request from the client, it further includes:

[0072] Receiving a configuration instruction;

[0073] According to the configuration instruction, configuring the corresponding business service, source address, and access policy in the API authorization service.

[0074] It can be understood that the configuration instruction is generally generated by a management node in the network. The management node is provided with a configuration port, and the user transmits configuration information to the management node through this configuration port. After receiving the configuration information, the management node will generate a configuration instruction and send it to the relevant gateway through the network. The configuration port includes but is not limited to human-computer interaction interfaces such as a UI interface. The specific type is not limited in this embodiment and all belong to the protection scope of this embodiment.

[0075] In some specific embodiments, the process of the receiving module 1 receiving the configuration instruction includes:

[0076] Receiving the configuration instruction corresponding to the API authorization service of this site through the gateway.

[0077] In some specific embodiments, the process of the query module 03 configuring the corresponding business service, source address, and access policy in the API authorization service according to the configuration instruction includes:

[0078] According to the configuration instruction, creating an access policy object with a preset expiration date on istio and K8S, and configuring the corresponding business service, source address, and access policy of the access policy object in the API authorization service.

[0079] In some specific embodiments, the query module 03 is further configured to:

[0080] When the creation duration of any one of the access policy objects exceeds the preset expiration period, delete the access policy object.

[0081] It can be understood that the action of deleting the expired access policy object continuously occurs during the execution of steps S1 - S4. The preset expiration period is determined according to the configuration instruction when the access policy is created and belongs to the configuration parameters. After the creation duration of the access policy object exceeds the preset expiration period, the access policy object and related access policies can be directly deleted, or the access policy object can also be set to an invalid state. When the next configuration instruction is for this access policy object, it can be restored from invalid to valid.

[0082] In some specific embodiments, the microservice access request is a token access request carried in the HTTP message header.

[0083] In some specific embodiments, the access policy includes: microservice level, and / or service interface, and / or service call method.

[0084] It can be understood that in this embodiment, after receiving the microservice access request from the client, the business service requested by the client and the source address corresponding to the client can be determined according to the content of the microservice access request. Query the access policy for the source address of this client for this business service under the API authorization service, that is, query whether the source address of this client has the access permission to use the business service. If so, authorize the client according to the access policy pre - stored in the API authorization service and allow the client to access the business service according to this access policy. If not, it proves that the current client is not authorized for this business service, and the access of the client to the business service is refused.

[0085] It can be understood that the microservice access request is specifically an access request in the form of a token. For the same microservice access request, there is only one corresponding access policy under the API authorization service. However, the same client can use different token access requests to obtain different access policies. Different token access requests can correspond to different business services or different access policies for the same business service. Whether a specific token access request can be authorized depends on whether there is a corresponding access policy preset in the API authorization service.

[0086] Further, it can be an access request carried by an HTTP message header. It can be understood that the Hyper Text Transfer Protocol (HTTP) is an application layer protocol applied to distributed, real-time, and hypermedia information systems. It is one of the most widely used network transmission protocols on the Internet. In fact, it establishes a standard for requests and responses between a client and a server through HTTP.

[0087] It can be understood that in this embodiment, different access policies are set for different source addresses and different business services. The dimensional descriptions of the access policies include but are not limited to: microservice level, and / or service interface, and / or service call method. Among them, the microservice level includes the application level, the service interface includes the service interfaces allowed to be provided to the current client among multiple available service interfaces of a certain business service, and the service call method includes various method functions for calling services. In addition to the limitations on the access policies in these dimensions, different conditions can also be set in other dimensions as fine-grained management parameters for different source addresses and different business services, such as data volume limitations, expiration date limitations, response speed or time period limitations, etc., to provide users with diversified microservice access control.

[0088] The embodiment of the present application also discloses an electronic device, including a processor 11 and a memory 12; wherein, when the processor 11 executes the computer program saved in the memory 12, the following steps are implemented:

[0089] Receive a microservice access request from a client;

[0090] Determine the business service requested by the client and the source address corresponding to the client according to the microservice access request;

[0091] Query whether there is an access policy for the source address in the business service under the API authorization service;

[0092] If so, authorize the client to access the business service according to the access policy;

[0093] If not, reject the client's access to the business service.

[0094] The embodiment of the present application sets access policies corresponding to different business services and source addresses. Only when the source address exists in the business service of the API authorization service, the client is allowed to access according to the access policy. The present application determines different levels of access permissions for different clients through the access policy, effectively improving the security of microservice business service access.

[0095] In some specific embodiments, when the processor 11 executes the computer subroutine stored in the memory 12, the following steps may be specifically implemented:

[0096] Receive a configuration instruction;

[0097] According to the configuration instruction, configure the corresponding business service, source address, and access policy in the API authorization service.

[0098] It can be understood that the configuration instruction is generally generated by a management node in the network. The management node is provided with a configuration port, and the user transmits configuration information to the management node through this configuration port. After receiving the configuration information, the management node generates a configuration instruction and sends it to the relevant gateway through the network. The configuration port includes, but is not limited to, human-computer interaction interfaces such as a UI interface. The specific type is not limited in this embodiment and all belong to the protection scope of this embodiment.

[0099] In some specific embodiments, when the processor 11 executes the computer subroutine stored in the memory 12, the following steps may be specifically implemented:

[0100] Receive the configuration instruction corresponding to the API authorization service of this site through the gateway.

[0101] In some specific embodiments, when the processor 11 executes the computer subroutine stored in the memory 12, the following steps may be specifically implemented:

[0102] According to the configuration instruction, create an access policy object with a preset expiration period on istio and K8S, and configure the corresponding business service, source address, and access policy of the access policy object in the API authorization service.

[0103] In some specific embodiments, when the processor 11 executes the computer subroutine stored in the memory 12, the following steps may be specifically implemented:

[0104] When the creation duration of any access policy object exceeds the preset expiration period, delete the access policy object.

[0105] It can be understood that the action of deleting the expired access policy object continuously occurs during the execution of steps S1 - S4. The preset expiration period is determined according to the configuration instruction when the access policy is created. It belongs to the configuration parameters. After the creation market of the access policy object exceeds the preset expiration period, the access policy object and related access policies can be directly deleted, or the access policy object can also be set to an invalid state. Wait until the next configuration instruction for this access policy object, and then restore it from invalid to valid.

[0106] In some specific embodiments, the microservice access request is a token access request carried in the HTTP header.

[0107] In some specific embodiments, the access policy includes: microservice level, and / or service interface, and / or service call method.

[0108] It can be understood that in this embodiment, after receiving the microservice access request from the client, the business service requested by the client and the source address corresponding to the client can be determined according to the content of the microservice access request. The access policy for the source address of the client for this business service is queried under the API authorization service, that is, it is queried whether the source address of the client has the access right to use the business service. If so, the client is authorized according to the access policy pre-stored in the API authorization service, and the client is allowed to access the business service according to this access policy. If not, it proves that the current client is not authorized for this business service, and the client's access to the business service is rejected.

[0109] It can be understood that the microservice access request is specifically an access request in the form of a token. For the same microservice access request, there is only one corresponding access policy under the API authorization service. However, the same client can use different token access requests to obtain different access policies. Different token access requests can correspond to different business services, or different access policies for the same business service. Whether a specific token access request can be authorized depends on whether the corresponding access policy is preset in the API authorization service.

[0110] Further, it is preferably a token access request carried in the HTTP header. It can be understood that the Hyper Text Transfer Protocol (HTTP) is an application layer protocol applied to distributed, collaborative, and hypermedia information systems, and is the most widely used network transmission protocol on the Internet. In fact, a standard for requests and responses between the client and the server is established through HTTP.

[0111] It can be understood that in this embodiment, different access policies are set for different source addresses and different business services. The dimensional descriptions of the access policies include but are not limited to: microservice level, and / or service interface, and / or service call method. Among them, the microservice level includes the application level, the service interface includes the service interfaces allowed to be provided to the current client among multiple available service interfaces of a certain business service, and the service call method includes various method functions for calling services. In addition to the limitations on the access policies in these dimensions, different conditions can also be set in other dimensions as fine-grained management parameters for different source addresses and different business services, such as data volume limit, validity period limit, response speed or time period limit, etc., to provide users with diversified microservice access control.

[0112] Furthermore, the electronic device in this embodiment may further include:

[0113] An input interface 13, which is used to obtain computer programs imported from the outside and save the obtained computer programs into the memory 12. It can also be used to obtain various instructions and parameters transmitted from an external terminal device and transmit them to the processor 11 so that the processor 11 can perform corresponding processing using the above various instructions and parameters. In this embodiment, the input interface 13 may specifically include but is not limited to a USB interface, a serial interface, a voice input interface, a fingerprint input interface, a hard disk reading interface, etc.

[0114] An output interface 14, which is used to output various data generated by the processor 11 to the terminal device connected thereto, so that other terminal devices connected to the output interface 14 can obtain various data generated by the processor 11. In this embodiment, the output interface 14 may specifically include but is not limited to a USB interface, a serial interface, etc.

[0115] A communication unit 15, which is used to establish a remote communication connection between the electronic device and an external server, so that the electronic device can mount the image file to the external server. In this embodiment, the communication unit 15 may specifically include but is not limited to a remote communication unit based on wireless communication technology or wired communication technology.

[0116] A keyboard 16, which is used to obtain various parameter data or instructions input by the user by tapping the key caps in real time.

[0117] A display 17, which is used to display relevant information in the microservice access management process in real time, so that the user can timely understand the current situation of microservice access management.

[0118] A mouse 18, which can be used to assist the user in inputting data and simplify the user's operations.

[0119] Further, the embodiments of the present application also disclose a readable storage medium, where the readable storage medium includes a random access memory (RAM), an internal memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable hard disk, a CD-ROM, or any other form of storage medium known in the technical field. A computer program is stored in the readable storage medium, and when the computer program is executed by a processor, the following steps are implemented:

[0120] Receive a microservice access request from a client;

[0121] Determine the business service requested by the client and the source address corresponding to the client according to the microservice access request;

[0122] Query whether there is an access policy for the source address in the business service under the API authorization service;

[0123] If so, authorize the client to access the business service according to the access policy;

[0124] If not, reject the client's access to the business service.

[0125] The embodiments of the present application set access policies corresponding to different business services and source addresses. Only when the source address exists in the business service of the API authorization service, the client is allowed to access according to the access policy. The present application determines different levels of access permissions for different clients through the access policy, effectively improving the security of microservice business service access.

[0126] In some specific embodiments, when the computer subprogram stored in the readable storage medium is executed by a processor, the following steps can be specifically implemented:

[0127] Receive a configuration instruction;

[0128] According to the configuration instruction, configure the corresponding business service, source address, and access policy in the API authorization service.

[0129] It can be understood that the configuration instruction is generally generated by a management node in the network. The management node is provided with a configuration port, and the user transmits configuration information to the management node through this configuration port. After receiving the configuration information, the management node will generate a configuration instruction and send it to the relevant gateway through the network. The configuration port includes, but is not limited to, human-computer interaction interfaces such as a UI interface. The specific type is not limited in this embodiment and all belong to the protection scope of this embodiment.

[0130] In some specific embodiments, when the computer subroutine stored in the readable storage medium is executed by a processor, the following steps can be specifically implemented:

[0131] Receive, through a gateway, the configuration instruction corresponding to the API authorization service of this site.

[0132] In some specific embodiments, when the computer subroutine stored in the readable storage medium is executed by a processor, the following steps can be specifically implemented:

[0133] According to the configuration instruction, create an access policy object with a preset expiration period on istio and K8S, and configure the corresponding business service, source address, and access policy of the access policy object in the API authorization service.

[0134] In some specific embodiments, when the computer subroutine stored in the readable storage medium is executed by a processor, the following steps can be specifically implemented:

[0135] When the creation duration of any one of the access policy objects exceeds the preset expiration period, delete the access policy object.

[0136] It can be understood that the action of deleting the expired access policy object continuously occurs during the execution of steps S1 - S4. The preset expiration period is determined according to the configuration instruction when the access policy is created and belongs to the configuration parameters. After the creation duration of the access policy object exceeds the preset expiration period, the access policy object and related access policies can be directly deleted, or the access policy object can also be set to an invalid state. When the next configuration instruction is for this access policy object, it can be restored from invalid to valid.

[0137] In some specific embodiments, the microservice access request is a token access request carried in the HTTP message header.

[0138] In some specific embodiments, the access policy includes: microservice level, and / or service interface, and / or service call method.

[0139] It can be understood that in this embodiment, after receiving the microservice access request from the client, the business service requested by the client and the source address corresponding to the client can be determined according to the content of the microservice access request. Query the access policy for the source address of this client for this business service under the API authorization service, that is, query whether the source address of this client has the access permission to use the business service. If so, authorize the client according to the access policy pre - stored in the API authorization service and allow the client to access the business service according to this access policy. If not, it proves that the current client is not authorized for this business service, and the access of the client to the business service is rejected.

[0140] It is understandable that the microservice access request is specifically an access request in the form of a token. For the same microservice access request, there is only one access policy under the API authorization service. However, the same client can use different token access requests to obtain different access policies. Different token access requests can correspond to different business services or different access policies for the same business service. Whether a specific token access request can be authorized depends on whether the corresponding access policy is preset in the API authorization service.

[0141] Furthermore, it can be an access request carried by the HTTP message header. It is understandable that the Hyper Text Transfer Protocol (HTTP) is an application layer protocol applied to distributed, collaborative, and hypermedia information systems. It is the most widely used network transmission protocol on the Internet. In fact, it establishes a standard for requests and responses between the client and the server through HTTP.

[0142] It is understandable that in this embodiment, different access policies are set for different source addresses and different business services. The dimensional descriptions of the access policies include but are not limited to: microservice level, and / or service interface, and / or service call method. Among them, the microservice level includes the application level. The service interface includes the service interfaces that are allowed to be provided to the current client among the multiple available service interfaces of a certain business service. The service call method includes various method functions for calling services. In addition to the limitations on the access policies in these dimensions, different conditions can also be set in other dimensions as fine-grained management parameters for different source addresses and different business services, such as data volume limitations, expiration date limitations, response speed or time period limitations, etc., to provide users with diversified microservice access control.

[0143] Finally, it should also be noted that in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "including", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "including a..." does not exclude the existence of additional identical elements in the process, method, article or device including the said element.

[0144] The above has introduced in detail a microservice access management method, system, electronic device and readable storage medium provided by the present invention. Specific examples are used in this article to elaborate on the principle and implementation manner of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention; at the same time, for those of ordinary skill in the art, according to the idea of the present invention, there will be changes in the specific implementation manner and application scope. In summary, the content of this specification should not be construed as a limitation to the present invention.

Claims

1. A microservice access management method, characterized in that, Including: Receiving a configuration instruction; According to the configuration instruction, configuring corresponding business services, source addresses, and access policies in the API authorization service; The access policy includes: microservice level, and / or service interface, and / or service call method. The service interface includes the service interfaces allowed to be provided to the current client among multiple available service interfaces of a certain business service. The service call method includes various method functions for calling services; Receiving a microservice access request from a client; the microservice access request is a token access request. The same client uses different token access requests to obtain different access policies, and different token access requests correspond to different business services or different access policies for the same business service; Determining the business service requested by the client and the source address corresponding to the client according to the microservice access request; Querying whether there is an access policy for the source address in the business service under the API authorization service; If so, authorizing the client to access the business service according to the access policy; If not, rejecting the client's access to the business service; The process of configuring corresponding business services, source addresses, and access policies in the API authorization service according to the configuration instruction includes: According to the configuration instruction, creating an access policy object with a preset expiration period on istio and K8S, and configuring the corresponding business service, source address, and access policy of the access policy object in the API authorization service; When the creation duration of any access policy object exceeds the preset expiration period, deleting the access policy object.

2. The microservice access management method according to claim 1, wherein The process of receiving the configuration instruction includes: Receiving the configuration instruction corresponding to the API authorization service of this site through the gateway.

3. The microservice access management method according to claim 1, wherein The microservice access request is a token access request carried in the HTTP message header.

4. A microservice access management system, characterized in that, Including: A receiving module for receiving a configuration instruction; According to the configuration instruction, configuring corresponding business services, source addresses, and access policies in the API authorization service; The access policy includes: microservice level, and / or service interface, and / or service call method; receiving a microservice access request from a client; the microservice access request is a token access request. The same client uses different token access requests to obtain different access policies, and different token access requests correspond to different business services or different access policies for the same business service; An analysis module for determining the business service requested by the client and the source address corresponding to the client according to the microservice access request; A query module for querying whether there is an access policy for the source address in the business service under the API authorization service. If so, authorizing the client to access the business service according to the access policy. If not, rejecting the client's access to the business service; The receiving module is further configured to: according to the configuration instruction, create an access policy object with a preset expiration period on Istio and K8S, and configure the corresponding business service, source address, and access policy of the access policy object in the API authorization service; The query module is further configured to delete the access policy object when the creation duration of any one of the access policy objects exceeds the preset expiration period.

5. An electronic device, characterized in that, Comprising: A memory for storing a computer program; A processor for implementing the steps of the microservice access management method according to any one of claims 1 to 3 when executing the computer program.

6. A readable storage medium, characterized in that, A computer program is stored on the readable storage medium, and when the computer program is executed by the processor, the steps of the microservice access management method according to any one of claims 1 to 3 are implemented.

Images