Interface call request processing methods, devices, equipment, media and program products

Abstract

This application provides an interface call request processing method, apparatus, device, medium, and program product. It relates to the field of request processing technology. The method includes: receiving an interface call request sent by an application container in the same container group as the sidecar container; encrypting the identification information and security node number of the service requesting end according to a key and an encryption algorithm to generate verification information; the key and encryption algorithm are pre-distributed to the sidecar containers in each container group by a security management system; sending the verification information as the request header of the interface call request to the service provider, so that the service provider parses the request header in the interface call request to obtain the verification information and performs security verification on the service requesting end. The above method, by generating verification information using the key and encryption algorithm pre-distributed to the sidecar containers by the security management system, avoids the use of service mesh certificates, thereby avoiding the verification failure problem caused by certificate expiration.

Description

Technical Field

[0001] This application relates to the field of request processing technology, and in particular to an interface call request processing method, apparatus, device, medium and program product. Background Technology

[0002] As the number of existing backend microservices increases, when using cloud platforms and service meshes (Istio) to manage and control backend microservices, there is a need for unified management of interface call permissions, as well as more flexible permission configuration and more granular permission verification mechanisms.

[0003] The existing service mesh (Istio) uses the SSL (Secure Socket Layer) protocol, specifically the mTLS (Mutual Transport Layer Security) architecture, for API call verification. The sidecar container and the mesh management terminal use the SDS (Secret Discovery Service) protocol for certificate issuance and authentication. However, certificates issued using this method have expiration dates and must be renewed periodically; failure to do so will result in verification failure. Furthermore, this method lacks granular permission management for API verification, limiting access only to the application level and not to the API level. Summary of the Invention

[0004] This application provides an interface call request processing method, apparatus, device, medium, and program product that avoids the use of service mesh certificates, thereby avoiding the problem of verification failure caused by certificate expiration due to failure to update certificates in a timely manner.

[0005] Firstly, this application provides an interface call request processing method, executed by a sidecar container of a service requesting end, comprising: receiving an interface call request sent by an application container in a container group where the sidecar container is located; encrypting the identification information and security node number of the service requesting end according to a key and an encryption algorithm to generate verification information; wherein the key and the encryption algorithm are pre-distributed to the sidecar containers of each container group by a security management system; sending the verification information as the request header of the interface call request to a service provider, so that the service provider parses the request header in the interface call request to obtain the verification information and performs security verification on the service requesting end.

[0006] Secondly, this application also provides an interface call request processing method, executed by a sidecar container on the service provider side, comprising: receiving an interface call request sent by a service requesting end, and parsing the interface call request; obtaining verification information from the request header of the interface call request; wherein the verification information is generated by the sidecar container on the service requesting end by encrypting the identification information and security node number of the service requesting end according to a key and an encryption algorithm; and verifying the service requesting end according to the verification information.

[0007] Thirdly, this application also provides an interface call request processing method, executed by a security policy management center, comprising: determining the type of permission configuration information for an interface requiring permission configuration; wherein the type of permission configuration information includes a type of service request client that is allowed to call the interface or a type of service request client that is not allowed to call the interface; determining the service request client according to the type of permission configuration information, and generating permission configuration information according to the interface and the corresponding service request client; synchronizing the permission configuration information to a grid server, and having the grid server distribute the permission configuration information to the sidecar containers in each container group, so that the sidecar containers process the interface call request according to the permission configuration information.

[0008] Fourthly, this application also provides an interface call request processing apparatus applied to a sidecar container of a service request end, comprising: an interface call request receiving module, configured to receive an interface call request sent by an application container in a container group where the sidecar container is located; a verification information generation module, configured to encrypt the identification information and security node number of the service request end according to a key and an encryption algorithm to generate verification information; wherein the key and the encryption algorithm are pre-distributed to the sidecar containers of each container group by a security management system; and an interface call request sending module, configured to send the verification information as the request header of the interface call request to the service provider end, so that the service provider end can parse the request header in the interface call request to obtain the verification information and perform security verification on the service request end.

[0009] Fifthly, this application also provides an interface call request processing apparatus applied to a sidecar container on a service provider side, comprising: an interface call request parsing module, configured to receive an interface call request sent by a service requesting end and parse the interface call request; a verification information acquisition module, configured to acquire verification information from the request header of the interface call request; wherein the verification information is generated by the sidecar container on the service requesting end by encrypting the identification information and security node number of the service requesting end according to a key and an encryption algorithm; and a service requesting end verification module, configured to verify the service requesting end according to the verification information.

[0010] Sixthly, this application also provides an interface call request processing device applied to a security policy management center, comprising: a permission configuration information type determination module, used to determine the type of permission configuration information for an interface requiring permission configuration; wherein the type of permission configuration information includes a type of service request client that reflects the permission to call the interface or a type of service request client that reflects the permission not to call the interface; a permission configuration information generation module, used to determine the service request client according to the type of permission configuration information, and generate permission configuration information according to the interface and the corresponding service request client; and a permission configuration information synchronization module, used to synchronize the permission configuration information to a grid server, and the grid server distributes the permission configuration information to the sidecar containers in each container group.

[0011] The interface call request processing method, apparatus, device, medium, and program product provided in this application receive interface call requests sent by application containers in the container group where the sidecar container is located; encrypt the identification information and security node number of the service requesting end according to a key and an encryption algorithm to generate verification information; wherein, the key and the encryption algorithm are pre-distributed to the sidecar containers of each container group by the security management system; and send the interface call request to the service provider as the request header of the interface call request, so that the service provider can parse the request header in the interface call request to obtain the verification information and perform security verification on the service requesting end. The above scheme generates verification information by using a key and encryption algorithm pre-distributed to the sidecar container by the security management system, avoiding the use of service mesh certificates, thereby avoiding the problem of verification failure caused by certificate expiration due to failure to update certificates in a timely manner. Attached Figure Description

[0012] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0013] Figure 1 A flowchart illustrating an interface call request processing method executed by the sidecar container of the service requesting end, as provided in Embodiment 1 of this application;

[0014] Figure 2 This is a timing diagram of sending an interface call request provided in Embodiment 1 of this application;

[0015] Figure 3 A flowchart illustrating an interface call request processing method executed by the sidecar container of the service provider, as provided in Embodiment 2 of this application;

[0016] Figure 4A flowchart illustrating another interface call request processing method executed by the sidecar container of the service provider, as provided in Embodiment 3 of this application;

[0017] Figure 5 This is a timing diagram for verifying an interface call request, provided in Embodiment 3 of this application.

[0018] Figure 6 A flowchart illustrating an interface call request processing method executed by a security policy management center, provided in Embodiment 4 of this application;

[0019] Figure 7 This is a timing diagram for the synchronous distribution of permission configuration information provided in Embodiment 4 of this application;

[0020] Figure 8 A complete flowchart illustrating the specific implementation of an interface call request processing method provided in Embodiment 5 of this application;

[0021] Figure 9 This is a system architecture diagram of an interface call request processing method provided in Embodiment 5 of this application;

[0022] Figure 10 This is a schematic diagram of the interface call request processing device of the sidecar container configured on the service request end, as provided in Embodiment Six of this application;

[0023] Figure 11 This is a schematic diagram of the interface call request processing device for the sidecar container configured on the service provider side, as provided in Embodiment 7 of this application.

[0024] Figure 12 This is a schematic diagram of the interface call request processing device configured in the security policy management center according to Embodiment 8 of this application;

[0025] Figure 13 This is a schematic diagram of the structure of the electronic device provided in Embodiment 9 of this application.

[0026] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0027] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims. The acquisition, transmission, storage, use, and processing of data in the technical solutions of this application all comply with the relevant provisions of national laws and regulations.

[0028] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0029] Terminology Explanation:

[0030] Service Mesh: A service mesh serves as the infrastructure layer for inter-service communication. It is a lightweight, high-performance network proxy that provides secure, fast, and reliable inter-service communication. The service mesh is deployed alongside the actual application but remains transparent to it.

[0031] Istio: A fully open-source service mesh that builds on top of existing distributed applications in a transparent layer. It is also a platform that provides various APIs (Application Programming Interfaces) that can be integrated with any logging platform, monitoring system, or policy system.

[0032] Mesh server: Used to manage sidecar containers, maintain long links with sidecar containers, and distribute information such as rules, configurations, and addresses.

[0033] Sidecar Container: An important container design pattern that can provide additional services or functions to an application container without modifying the application code.

[0034] Pod: The smallest deployable computing unit in a container orchestration system. It can contain one or more containers that share the same network namespace, storage volume and other resources.

[0035] JWT, or JOSN Web Token, is an open standard that defines a compact, self-contained way to securely transmit information between parties as a JSON (JavaScript Object Notation) object.

[0036] SA: The server-side component used to distribute keys and security policies. The security SDK (Software Development Kit) can encrypt and decrypt data based on the keys and security policies it distributes.

[0037] Example 1

[0038] Figure 1 This is a flowchart illustrating an interface call request processing method executed by a sidecar container on the service requesting end, as provided in Embodiment 1 of this application. This embodiment is applicable to processing interface call requests. Typically, this embodiment is applicable to processing interface call requests between different service objects located within the same cloud container. This method can be executed by an interface call request processing device applied to the sidecar container on the service requesting end. This interface call request processing device can be implemented in hardware and / or software, and can be configured in an electronic device. Figure 1 As shown, this method is executed by the sidecar container on the service requesting end, and includes:

[0039] S110, Receive the interface call request sent by the application container in the same container group as the sidecar container.

[0040] Sidecar containers are an important container design pattern that can provide additional services or functionalities to application containers without modifying the application code. Application containers are a modern deployment strategy that can run on different operating systems and hardware platforms to provide a wide variety of interface services. Typically, sidecar containers and application containers reside in the same container group, allowing the sidecar container to assist the application container in providing interface services. In this embodiment, the reasons for generating interface call requests can be diverse, such as business logic needs, data acquisition and synchronization, event-driven architecture, asynchronous processing, and user interaction. For example, an online shopping application might need to call a payment service to process user payment requests.

[0041] Since the sidecar container and the application container reside in the same container group, i.e., a Pod, when the application container sends an API call request, the sidecar container can receive the request through the Pod's internal network interface localhost. This method is relatively simple and direct. In some cases, a ClusterIP-type Service can be created to enable communication between the sidecar container and the application container to receive API call requests from the application container; however, this method increases network overhead and complexity. In this embodiment, the Istio service mesh is used; therefore, the traffic management and inter-service communication functions provided by the service mesh can also be used to receive API call requests from the application container.

[0042] In this embodiment of the application, after receiving the interface call request sent by the application container in the container group where the sidecar container is located, the method further includes:

[0043] Obtain the service provider information from the interface call request; determine the address of the service provider based on the service provider information, and send the interface call request to the service provider based on the address of the service provider.

[0044] The service provider is the provider of the service required in the API call request, and it is usually located in the same cloud container as the service requesting party. The information of the service provider in the API call request generally includes service name, version, and other information to identify the service provider.

[0045] In this embodiment of the application, when an application container wants to call the interface of a certain service, it usually needs to know the address of the service provider. Therefore, after receiving the interface call request sent by the application container, it is necessary to first parse the interface call request, obtain the information of the service provider in the interface call request, such as the service name, version, etc., and determine the address of the service provider based on this, and then send the interface call request to the service provider based on the address of the service provider.

[0046] For example, after obtaining the service provider information from the API call request, the service requester's sidecar container can send a query request containing the service provider's information, such as service name and version, to the service registry center, and obtain the service provider's address information from the service provider's details returned by the service registry center.

[0047] For example, a mapping table between service provider information and server address can be pre-established. After obtaining the service provider information in the interface call request, the address information of the service provider can be determined from the mapping table based on this information.

[0048] S120. Based on the key and encryption algorithm, encrypt the identification information and security node number of the service request end to generate verification information; wherein, the key and encryption algorithm are pre-distributed to the sidecar containers of each container group by the security management system.

[0049] The identification information of the service requester is its service metadata information, used to identify the service requester. The security node number of the service requester is used to identify its encryption algorithm; different service requesters have different security node numbers and different encryption algorithms. In this embodiment, the security management system is the SA, used to distribute keys and encryption algorithms, such as MD5 and SHA256. In this embodiment, verification information is generated by encrypting the identification information and security node number of the service requester using a JWT method, based on the key and encryption algorithm.

[0050] In this embodiment of the application, verification information is generated by encrypting the identification information and security node number of the service requesting end according to the key and encryption algorithm, including:

[0051] Generate the header data portion of the verification information according to the type of the verification information; generate the payload data portion of the verification information according to the identification information and the security node number; and sign the identification information and the security node number according to the key and encryption algorithm to generate the signature data portion of the verification information.

[0052] In the JWT encryption method, the header data part is used to describe the metadata of the JWT, the payload data part is used to transmit the data that needs to be transmitted, and the signature data part is the signature of the header data part and the payload data part, which is used to encrypt the first two parts of information.

[0053] In this embodiment, since the verification information is generated using JWT encryption, the type of the verification information is JWT, which can be used as the header data portion of the verification information. The service requester's identification information is used to identify the service requester, enabling the service provider to clearly identify the service requester and provide the service. The security node number is used to identify the encryption algorithm of the service requester, enabling the service provider to accurately parse the encrypted verification information. Therefore, the identification information and the security node number can be used as the payload data portion of the verification information. Subsequently, based on the key and encryption algorithm pre-issued by the security management system, the header data portion and the payload data portion can be signed (i.e., encrypted) using the security verification toolkit SDK integrated in the service requester's sidecar container, generating the signed data portion of the verification information.

[0054] Compared to existing technologies that use certificates and TLS for encryption, this embodiment of the application pre-distributes the key and encryption algorithm to the sidecar container through a security management system (SA), and encrypts the information using a security SDK integrated in the sidecar container. This avoids the use of service mesh certificates and eliminates concerns about verification failure due to certificate expiration caused by failure to update them in time. In this embodiment of the application, before encrypting the identification information and security node number of the service requesting end according to the key and encryption algorithm to generate verification information, the method further includes:

[0055] Receive the keys and encryption algorithms corresponding to each sidecar container pre-issued by the security management system; and retrieve the key and encryption algorithm corresponding to the sidecar container from the keys and encryption algorithms issued by the security management system based on the security node number of the sidecar container.

[0056] In this embodiment, when the security management system (SA) pre-distributes keys and encryption algorithms, it needs to establish a secure communication channel between itself and each sidecar container to ensure that the keys and encryption algorithms are not stolen or tampered with during transmission. Each sidecar container, upon receiving the keys and encryption algorithms, needs to securely store them to prevent unauthorized access. In this embodiment, the keys and encryption algorithms pre-distributed by the security management system (SA) to each sidecar container include those used by different service requesting ends when encrypting information. Since different service requesting ends use different keys and encryption algorithms for information encryption, and the security node number of the service requesting end identifies the keys and encryption algorithms used, the key and encryption algorithm corresponding to that sidecar container can be retrieved from the keys and encryption algorithms distributed by the security management system based on the security node number of the sidecar container (i.e., the security node number of the service requesting end), and the information to be sent by that sidecar container can be encrypted.

[0057] In this embodiment of the application, before encrypting the identification information and security node number of the service requesting end according to the key and encryption algorithm to generate verification information, the method further includes:

[0058] The system receives a security policy from the security management system; the security policy is used to instruct the steps of executing the interface call request processing method; a security verification toolkit is generated by packaging the interface that executes the security policy according to the security policy, and the interface call request processing method is executed based on the security verification toolkit.

[0059] The security policy is used to instruct the steps for executing the API call request processing method, specifically, the steps related to information encryption and decryption within the API call request processing method. The security verification toolkit, or security SDK, is integrated into each sidecar container and is used to execute the API call request processing method, specifically, the steps related to information encryption and decryption within the API call request processing method.

[0060] In this embodiment, the security management system is also used to issue security policies to instruct relevant steps in the interface call request. After receiving the security policy, each sidecar container first determines the interface required to execute the security policy according to the security policy, then packages the determined interface to generate a security verification toolkit SDK, and integrates it into itself. When generating verification information, the security SDK is used to sign and encrypt the header data part and the effective data payload part of the verification information to generate the signature data part of the verification information. When the service requesting end acts as the service provider end, the security SDK is used to decrypt the verification information.

[0061] S130. Send the verification information as the request header of the interface call request to the service provider so that the service provider can parse the request header in the interface call request to obtain the verification information and perform security verification on the service requesting party.

[0062] In this embodiment, after generating verification information, it can be added to the header of the interface call request, serving as the request header of the interface call information. The interface call request with the added verification information is then sent to the service provider, allowing the service provider to parse the request header in the interface call request to obtain the verification information and perform security verification on the service request. For example, Figure 2 This illustrates a timing diagram for sending an interface call request, such as... Figure 2 As shown in the diagram, Service A is the service requester and Service B is the service provider. When the sidecar container of Service A receives the interface call request sent by the application container of Service A, it first determines the address of Service B, then generates verification information as the request header of the interface call request based on the service metadata and security node number of Service A, and finally sends the interface call request to Service B.

[0063] In this embodiment, after receiving the interface call request from the service requester, the service provider can parse the request using its sidecar container and obtain verification information from the request header. Based on this verification information, the service requester's identity and permissions are then securely verified. It is understood that this process includes decrypting the encrypted verification information, which is also performed through the Security Management System (SA) and the Security SDK. This avoids the use of service mesh certificates and eliminates concerns about certificate expiration and verification failure due to untimely certificate updates.

[0064] In this embodiment of the application, the method further includes:

[0065] Establish communication with the grid server via a long-lived connection; receive permission configuration information sent by the grid server, and determine whether the application sending the interface call request to the service requesting terminal has access permissions based on the permission configuration information.

[0066] The grid server manages the sidecar containers and maintains a long-lived connection with them for distributing rules, configurations, and addressing information. In this embodiment, the long-lived connection can be established via gRPC. Permission configuration information describes the permissions of the application sending the interface call request; this information can be configured through the security policy management center and distributed through the grid server.

[0067] In this embodiment of the application, the service requester can also act as the service provider for other service requesters. When the service requester acts as the service provider for other service requesters, it can authenticate the application that sends the interface call request to the service requester based on the permission configuration information issued by the grid service that communicates with it through a long connection, that is, verify whether it has the permission to call the interface.

[0068] This embodiment of the application receives an interface call request sent by an application container in the same container group as the sidecar container; it encrypts the identification information and security node number of the service requesting end according to a key and encryption algorithm to generate verification information; wherein, the key and encryption algorithm are pre-distributed to the sidecar containers in each container group by the security management system; the verification information is used as the request header of the interface call request and sent to the service provider, so that the service provider can parse the request header in the interface call request to obtain the verification information and perform security verification on the service requesting end. The above scheme generates verification information by using the key and encryption algorithm pre-distributed to the sidecar container by the security management system, avoiding the use of service mesh certificates, thereby avoiding the problem of verification failure caused by certificate expiration due to failure to update certificates in time.

[0069] Example 2

[0070] Figure 3 This is a flowchart illustrating an interface call request processing method executed by a sidecar container on the service provider side, as provided in Embodiment 2 of this application. This embodiment is applicable to situations involving the processing of interface call requests. Typically, this embodiment is applicable to processing interface call requests between different service objects located within the same cloud container. This method can be executed by an interface call request processing device applied to the sidecar container on the service provider side. This interface call request processing device can be implemented in hardware and / or software and can be configured in an electronic device. For details not described in this embodiment, such as definitions of terms, please refer to the above embodiments. Figure 3 As shown, the method includes:

[0071] S210. Receive the interface call request sent by the service requesting end and parse the interface call request.

[0072] The containerized architecture design allows both the service requester and the service provider to adopt a layout that combines sidecar containers and application containers. Similar to the service requester, the service provider is also contained in the same container group as the sidecar container and the application container, which has high flexibility and scalability.

[0073] In this embodiment, the sidecar container on the service requesting end encrypts the verification information and adds it to the API call request header. Then, based on the pre-determined address of the service provider, the API call request is sent to the service provider. The sidecar container on the service provider intercepts and receives the API call request sent by the service requesting end, and parses the received request to ensure that the format of the API call request conforms to the expected specifications. In practical applications, communication between the service requesting end and the service provider may be conducted via protocols such as HTTP or gRPC. The specific protocol chosen can be selected according to the actual situation, and this embodiment does not limit this choice.

[0074] S220. Obtain verification information from the request header of the interface call request; wherein, the verification information is generated by the sidecar container of the service requesting end encrypting the identification information and security node number of the service requesting end according to the key and encryption algorithm.

[0075] In this embodiment, after the service requester's sidecar container encrypts the service requester's identification information and security node number using a key and encryption algorithm to generate verification information, it adds the verification information to the header of the interface call request, making it the request header of the interface call information. Therefore, after the service provider's sidecar container receives the interface call request sent by the service requester, it can obtain the verification information from the request header of the interface call request to verify the service requester. Furthermore, since the verification information is transmitted in the request header of the interface call request, it does not interfere with the main content of the interface call request, making the parsing and processing of the interface call request simpler and more efficient.

[0076] S230. Verify the service requester based on the verification information.

[0077] The verification information obtained from the request header of the interface call request is still encrypted. Before verifying the service request client based on the verification information, the encrypted verification information needs to be decrypted so that the service request client can be verified based on the relevant content in the decrypted verification information. In this embodiment, the above decryption process is performed through the Security Management System (SA) and the Security SDK, avoiding the use of service mesh certificates and eliminating concerns about verification failure caused by certificate expiration due to failure to update certificates in a timely manner.

[0078] In this embodiment, verifying the service requester based on verification information can be done from two aspects: the verification information itself and the content of the decrypted verification information. Starting with the verification information itself, its integrity can be verified to determine whether it has been tampered with during transmission, thereby verifying the identity of the service requester. Starting with the content of the decrypted verification information, the permissions of the service requester can be verified based on the relevant information about the service requester within the verification information. By verifying the service requester based on the verification information, service security can be ensured.

[0079] The scheme in this embodiment receives an interface call request sent by the service requesting client and parses the request. It then obtains verification information from the request header. This verification information is generated by the service requesting client's sidecar container using a key and encryption algorithm to encrypt the service requesting client's identifier and security node number. The service requesting client is then verified based on this verification information. This scheme generates verification information using a key and encryption algorithm pre-distributed to the sidecar container by the security management system, avoiding the use of service mesh certificates and thus preventing verification failure due to certificate expiration caused by failure to update certificates in a timely manner.

[0080] Example 3

[0081] Figure 4 This is a flowchart of another interface call request processing method executed by the sidecar container of the service provider, provided in Embodiment 3 of this application. This embodiment is an optimization based on the above embodiment.

[0082] like Figure 4 As shown, the method in this embodiment specifically includes the following steps:

[0083] S310: Receive the interface call request sent by the service request client and parse the interface call request.

[0084] S320. Obtain verification information from the request header of the interface call request; wherein, the verification information is generated by the sidecar container of the service requesting end encrypting the identification information and security node number of the service requesting end according to the key and encryption algorithm.

[0085] S330: Based on the keys and encryption algorithms pre-issued by the security management system, authenticate the server requesting party according to the verification information.

[0086] In this embodiment, the sidecar container of the service provider also contains a key and decryption algorithm corresponding to the encryption algorithm pre-issued by the security management system, as well as a security SDK integrated within the sidecar container. The sidecar container can use the security SDK to decrypt the verification information based on the key and encryption algorithm pre-issued by the security management system, and then use the decrypted verification information to authenticate the server requesting client. This decryption process is performed through the security management system (SA) and the security SDK, avoiding the use of service mesh certificates and eliminating concerns about certificate expiration and verification failure due to untimely certificate updates.

[0087] In this embodiment of the application, based on the key and encryption algorithm pre-issued by the security management system, the authentication of the server requesting party is performed according to the verification information, including:

[0088] The verification information is decrypted based on the key pre-issued by the security management system and the decryption algorithm corresponding to the encryption algorithm; the signature data portion of the verification information is verified based on the identification information and the security node number in the payload data portion of the verification information.

[0089] The decryption algorithm corresponding to the encryption algorithm can be determined by the security node number in the payload data section. It can be understood that the security node number is used to identify the encryption algorithm used by the service requesting party. The encryption algorithm used by the service requesting party can be determined by the security node number, and then the corresponding decryption algorithm can be determined.

[0090] In this embodiment, the verification information is generated using JWT encryption. The encrypted part is mainly the signature data of the verification information. After determining the decryption algorithm corresponding to the encryption algorithm, the signature data of the verification information can be decrypted according to the key and the decryption algorithm. Simultaneously, since the signature data is generated by encrypting the header data and payload data, the signature data of the verification information can be verified by comparing the plaintext payload data identifier and security node number with the corresponding content of the decrypted signature data. This verifies whether the verification information has been tampered with during transmission, thereby completing the authentication of the server requesting party.

[0091] In this embodiment of the application, the signature data portion of the verification information is verified based on the identification information and the security node number in the payload data portion of the verification information, including:

[0092] Based on the security node number, retrieve the key and encryption algorithm corresponding to the sidecar container of the service requesting end from the key issued by the security management system and the encryption algorithm; based on the key and the encryption algorithm, sign the identification information and the security node number in the payload data part of the verification information; compare the signed result with the signature data part of the verification information to verify the signature data part of the verification information.

[0093] In this embodiment, the keys and encryption algorithms pre-distributed by the security management system (SA) to each sidecar container include those used by different service requesters when encrypting information. Therefore, the sidecar container of the service provider can retrieve the key and encryption algorithm corresponding to its own sidecar container from the pre-distributed keys and encryption algorithms by the security management system (SA) based on the security node number of the service requester. Then, using the security SDK integrated in the sidecar container, the identification information and security node number in the payload data portion of the verification information are signed based on the retrieved key and encryption algorithm. Finally, the signed result is compared with the signature data portion of the verification information to determine if they are consistent, thus verifying the signature data portion of the verification information.

[0094] S340. Verify the interface call permissions of the service requesting party based on the identification information in the verification information.

[0095] The identification information is the service metadata information of the service requesting party. It is transmitted in plaintext through the payload data part of the verification information and is used to uniquely identify the service requesting party.

[0096] In this embodiment of the application, the verification of the interface call permission of the service requesting end is performed based on the identification information in the verification information, including:

[0097] The identification information is obtained from the payload portion of the verification information; based on the permission configuration information sent by the grid server and the identification information, it is determined whether the service requesting end has interface call permission.

[0098] In this embodiment, after obtaining the identification information of the service requester from the plaintext payload data, the sidecar container of the service provider can authenticate the service requester identified by the identification information based on the permission configuration information issued by the mesh server with which it communicates via a long-lived connection. This authentication verifies whether the service requester has the necessary API call permissions. It should be noted that the permission configuration information may include multiple authentication rules. If any authentication rule is not met, the API call request terminates, and an error code or message indicating API call failure is returned to the service requester. If all authentication rules are met, it indicates that the service requester has API call permissions.

[0099] In this embodiment of the application, after determining whether the service requesting end has interface call permissions based on the permission configuration information sent by the grid server and the identification information, the method further includes:

[0100] If the service requesting end has interface call permission, then the interface call request is sent to the application container in the container group where the sidecar container is located, so that the application container can process the interface call request.

[0101] In this embodiment, if the service requesting client has API call permissions, the sidecar container of the service provider will determine that the service requesting client is legitimate and trusted. In this case, the sidecar container forwards the API call request to the application container in the same container group, allowing the application container to process the API call request. In this embodiment, using the Istio service mesh, the forwarding of API call requests from the sidecar container to the application container can be achieved through the traffic management and inter-service communication functions provided by the service mesh.

[0102] For example, Figure 5 A sequence diagram for verifying an interface call request is shown, such as... Figure 5 As shown in the diagram, Service A is the service requester and Service B is the service provider. When the sidecar container of Service B receives the interface call request sent by Service A, it parses the interface call request, obtains the verification information from the request header of the interface call request, verifies the identity of the server requester based on the verification information, verifies the interface call permission of the service requester based on the identification information, and finally sends the interface call request to Service B.

[0103] The scheme in this embodiment receives an interface call request sent by the service requesting client and parses the request. It then obtains verification information from the request header. This verification information is generated by the service requesting client's sidecar container using a key and encryption algorithm to encrypt the service requesting client's identification information and security node number. Finally, it authenticates the server requesting client based on the verification information using a key and encryption algorithm pre-issued by the security management system. The scheme also verifies the service requesting client's interface call permissions based on the identification information within the verification information. This scheme decrypts the verification information using a key and encryption algorithm pre-issued by the security management system to the sidecar container, thereby authenticating the server requesting client's identity and interface call permissions. This avoids the use of service mesh certificates, preventing verification failure due to certificate expiration caused by untimely certificate updates.

[0104] Example 4

[0105] Figure 6 This is a flowchart illustrating an interface call request processing method executed by a security policy management center, as provided in Embodiment 4 of this application. This embodiment is applicable to situations involving the processing of interface call requests. Typically, this embodiment is applicable to processing interface call requests between different service objects located within the same cloud container. This method can be executed by an interface call request processing device applied to the security policy management center. This device can be implemented in hardware and / or software and can be configured in an electronic device. For details not described in this embodiment, such as definitions of terms, please refer to the above embodiments. Figure 6 As shown, the method includes:

[0106] S410. For interfaces that require permission configuration, determine the type of permission configuration information; wherein, the type of permission configuration information includes service requesters that are allowed to call the interface or service requesters that are not allowed to call the interface.

[0107] Specifically, when the permission configuration information is set to "Service requesters allowed to call the interface," only explicitly listed service requesters can call the interface. This type offers high security but low flexibility. When the permission configuration information is set to "Service requesters not allowed to call the interface," any service requester may attempt to call the interface unless explicitly prohibited. This type offers low security but high flexibility.

[0108] In this embodiment, the security policy management center can analyze interfaces requiring permission configuration to understand their functions and services, and assess their security requirements, such as data sensitivity and business importance, to determine the stringency of permission configuration. Then, based on the analysis results, the type of permission configuration information for the interface can be determined. If the interface has very high security requirements, or only requires specific service requesters to call it, the permission configuration information can be set to allow service requesters to call the interface. If the interface needs to prevent certain specific service requesters from calling it, the permission configuration information can be set to disallow service requesters to call the interface, clearly specifying which service requesters are prohibited from calling the interface. By determining the type of interface permission configuration information in the security policy management center, interface call permissions can be controlled more flexibly and with finer granularity. After learning the service requester's information, the service provider can clearly determine whether the service requester can call the interface.

[0109] In this embodiment of the application, before determining the type of permission configuration information for the interface requiring permission configuration, the method further includes:

[0110] The grid server collects all interfaces that all container groups can provide; in response to the user's interface selection operation on the visual interface of the security policy management center, it determines the interfaces that need permission configuration.

[0111] In this embodiment, a mesh server can monitor all services and container groups within the cluster. Through service discovery and reflection mechanisms, it automatically collects and organizes the interface information corresponding to each service, thus collecting all interfaces provided by all container groups. After collection, the collected interface information can be stored in a central database for subsequent querying and display. In this embodiment, a user-friendly visual interface can be built in the security policy management center to display all collected interface information and provide search, filtering, and categorization functions to help users quickly locate interfaces of interest. Users can browse and select interfaces requiring permission configuration through the visual interface, which supports multi-selection, allowing users to identify multiple interfaces requiring permission configuration at once.

[0112] S420. Determine the service request client based on the type of permission configuration information, and generate permission configuration information based on the interface and the corresponding service request client.

[0113] In this embodiment, after clarifying the permission configuration type of the interface, it is possible to identify which service request clients need to be included in the permission configuration based on the purpose and business logic of the interface, and generate permission configuration information based on the interface and the corresponding service request clients. It is important to note that when generating permission configuration information, only the minimum permissions required to complete the task should be granted to the service request client, which helps to reduce potential risks. Furthermore, after generating the permission configuration information, it can be reviewed periodically to ensure that it still meets business needs and security requirements. In this embodiment, generating permission configuration information based on the interface and the corresponding service request client includes:

[0114] A filter template is created based on the permission configuration information, and the filter template is bound to a preset container group to create a filter based on the permission configuration information.

[0115] The filter is used to filter service request clients that send API call requests to the service provider based on permission configuration information, preventing service request clients without API call permissions from calling the API. The filter template is used to dynamically generate specific filter instances based on permission configuration information.

[0116] In this embodiment, creating a filter template based on the permission configuration information can be achieved by writing filter code in a suitable programming language (such as Python) that can receive the permission configuration information as input and execute filtering logic based on it. Then, the fixed and variable parts of the filter code are separated, and the variable parts are defined as template parameters. Through this process, the filter template can be created. Afterward, the filter template is bound to a preset container group to create a filter based on the permission configuration information. As the permission configuration information of the interface differs, the values ​​of the template parameters also differ, thus generating filter instances with different configurations.

[0117] In this embodiment of the application, the service request client is determined according to the type of the permission configuration information, and permission configuration information is generated according to the interface and the corresponding service request client, including:

[0118] If the type of the permission configuration information reflects the type of service request client allowed to call the interface, then the service request client allowed to access the interface is determined; the interface is associated with the identification information of the service request client allowed to access the interface to generate permission configuration information, so that when the side vehicle container determines that the identification information of the service request client belongs to the identification information corresponding to the interface in the permission configuration information, it determines that the service request client has access permission to the corresponding interface.

[0119] In this embodiment, when the type of permission configuration information reflects the type of service request client allowed to call the interface, only explicitly listed service request clients can call the interface. In this case, the service request clients allowed to access the interface can be determined first, and then the interface can be associated with the identification information of the service request clients allowed to access the interface to generate permission configuration information. After the service provider's sidecar container obtains the identification information of the service provider in the interface call request, it can determine whether the identification information belongs to the identification information corresponding to the interface in the service provider's permission configuration information, that is, whether the identification information is associated with the corresponding interface of the service provider, to determine whether the service request client has access to the corresponding interface. If it is determined that the identification information of the service request client belongs to the identification information corresponding to the interface in the permission configuration information, it is determined that the service request client has access to the corresponding interface.

[0120] In this embodiment of the application, the service request client is determined according to the type of the permission configuration information, and permission configuration information is generated according to the interface and the corresponding service request client, including:

[0121] If the type of the permission configuration information reflects the type of service request client that is not allowed to call the interface, then the service request client that is not allowed to access the interface is determined, or the service request clients that are allowed to access the interface are removed from all service request clients to obtain the service request clients that are not allowed to access the interface; the interface is associated with the identification information of the service request client that is not allowed to access the interface to generate permission configuration information, so that the side vehicle container determines that the service request client has access to the corresponding interface if it determines that the identification information of the service request client does not belong to the identification information corresponding to the interface in the permission configuration information.

[0122] In this embodiment, when the type of permission configuration information reflects the type of service request client that is not allowed to call the interface, unless explicitly prohibited, any service request client may attempt to call the interface. In this case, the service request clients that are not allowed to access the interface can be identified first. Alternatively, if there are many service request clients that are not allowed to access the interface, the service request clients that are allowed to access the interface can be removed from all the service request clients. Then, the interface can be associated with the identification information of the service request clients that are not allowed to access the interface to generate permission configuration information. After the sidecar container of the service provider obtains the identification information of the service provider in the interface call request, it can determine whether the identification information belongs to the identification information corresponding to the interface in the permission configuration information of the service provider, that is, whether the identification information is associated with the corresponding interface of the service provider, to determine whether the service request client has access to the corresponding interface. If it is determined that the identification information of the service request client does not belong to the identification information corresponding to the interface in the permission configuration information, it is determined that the service request client has access to the corresponding interface.

[0123] S430. Synchronize permission configuration information with the grid server so that the grid server can send permission configuration information to the sidecar containers in each container group. This allows the sidecar containers to parse the request header in the interface call request to obtain the verification information, and then process the interface call request based on the permission configuration information and the verification information.

[0124] The verification information is generated by the sidecar container of the service requesting end encrypting the identification information and security node number of the service requesting end according to the key and encryption algorithm; the key and encryption algorithm are pre-distributed to the sidecar containers of each container group by the security management system.

[0125] In this embodiment, after configuring the permission configuration information type of the interface through the security policy management center and generating permission configuration information, the permission configuration information can be synchronized to the grid server. Then, via a long connection, the grid server distributes the permission configuration information to the sidecar containers in each container group. After receiving the permission configuration information from the grid server and parsing the request header of the received interface call request to obtain verification information, the sidecar container can process the interface call request according to the permission configuration information and the verification information, thereby achieving authentication and permission verification of the service requesting party that sent the interface call request.

[0126] In this embodiment, the permission configuration information is synchronized to the grid server, and the grid server distributes the permission configuration information to the sidecar containers in each container group, so that the sidecar containers can process interface call requests according to the permission configuration information, including:

[0127] For each combination of applications, components, services, and interfaces, the permission configuration information corresponding to that combination is determined according to the type of the permission configuration information; the permission configuration information corresponding to each combination is synchronized to the grid server, so that the grid server can distribute the permission configuration information corresponding to each combination to the service provider that provides the service corresponding to that combination.

[0128] Specifically, for combinations of applications and services, basic permission configurations can be determined for the entire application or service level, such as which services are public and which require authentication. For combinations of services and interfaces, detailed permission configurations can be defined for each interface under a service, such as which services can call which interfaces and perform which operations. For combinations of components and interfaces, if there are independent components in the architecture, permission configurations can be defined for the interaction between that component and the interface.

[0129] In this embodiment of the application, for each combination of application, component, service and interface, the overall permission configuration information corresponding to each combination can be determined according to the type of new configuration, and the permission configuration information corresponding to each combination can be synchronized to the grid server, so that the grid server can specifically distribute the permission configuration information corresponding to each combination to the service provider that provides the service corresponding to that combination.

[0130] For example, Figure 7 This illustrates a sequence diagram of the synchronous distribution of permission configuration information, such as... Figure 7 As shown, after the security policy management center generates the permission configuration information, it synchronizes the permission configuration information to the grid server, and then distributes the permission configuration information to the sidecar containers in each container group through the grid server.

[0131] The solution in this embodiment determines the type of permission configuration information for interfaces requiring permission configuration. This type includes service requesters that are allowed or disallowed to call the interface. The service requester is determined based on the type of permission configuration information, and permission configuration information is generated based on the interface and the corresponding service requester. The permission configuration information is synchronized with the grid server, enabling the grid server to distribute the permission configuration information to the sidecar containers in each container group. The sidecar containers then parse the request headers in the interface call request to obtain verification information, and process the interface call request based on the permission configuration information and the verification information. This solution, by determining the type of interface permission configuration information in the security policy management center, allows for more flexible and granular control of interface call permissions. After learning the information of the service requester, the service provider can clearly determine whether the service requester can call the service provider's interface.

[0132] Example 5

[0133] Figure 8This is a complete flowchart illustrating the specific implementation of an interface call request processing method provided in Embodiment 5 of this application. Figure 9 This is a system architecture diagram for an interface call request processing method provided in Embodiment 5 of this application. In this embodiment, the service requester is Service A, the service provider is Service B, and the security policy management center is SA. Figure 8 As shown, the method in this embodiment specifically includes the following steps:

[0134] S510. Generate permission configuration information through the security policy center, synchronize the permission configuration information to the grid server, and the grid server distributes the permission configuration information to the sidecar containers of service A and service B.

[0135] S520: The security management system pre-distributes keys and encryption algorithms to the sidecar containers of services A and B.

[0136] S530. The sidecar container of service A receives the interface call request sent by the application container in the same container group as the sidecar container, and encrypts the identification information and security node number of service A according to the key and encryption algorithm to generate verification information. The verification information is used as the request header of the interface call request and sent to service B as the interface call request.

[0137] S540, Service B's sidecar container receives the interface call request sent by Service A, parses the interface call request, obtains the verification information from the request header of the interface call request, and verifies Service A based on the verification information.

[0138] S550. If service A has interface call permission, then send an interface call request to the application container in the same container group as the sidecar container of service B, so that the application container of service B can process the interface call request.

[0139] Example 6

[0140] Figure 10 This is a schematic diagram of an interface call request processing device provided in Embodiment Six of this application. This device can execute the interface call request processing method executed by the sidecar container of the service request end in this application. Figure 10 As shown, the device is configured on the electronic device corresponding to the sidecar container at the service request end, including: an interface call request receiving module 610, a verification information generation module 620, and an interface call request sending module 630;

[0141] The interface call request receiving module 610 is used to receive interface call requests sent by the application container in the container group where the sidecar container is located.

[0142] The verification information generation module 620 is used to encrypt the identification information and security node number of the service request terminal according to the key and the encryption algorithm to generate verification information; wherein, the key and the encryption algorithm are pre-distributed to the sidecar containers of each container group by the security management system;

[0143] The interface call request sending module 630 is used to send the verification information as the request header of the interface call request to the service provider, so that the service provider can parse the request header in the interface call request to obtain the verification information and perform security verification on the service requesting end.

[0144] In some embodiments, the verification information generation module 620 encrypts the identification information and security node number of the service requesting end according to the key and encryption algorithm to generate verification information, specifically including: generating the header data portion of the verification information according to the type of the verification information; generating the payload data portion of the verification information according to the identification information and the security node number; and signing the identification information and the security node number according to the key and encryption algorithm to generate the signature data portion of the verification information.

[0145] In some embodiments, the apparatus further includes: a long-connection communication establishment module for establishing communication with the grid server via a long-connection; and an access permission determination module for receiving permission configuration information sent by the grid server to determine whether the application sending the interface call request to the service requesting terminal has access permissions based on the permission configuration information.

[0146] In some embodiments, the apparatus further includes: a service provider information acquisition module, configured to acquire service provider information in the interface call request; and a service provider address determination module, configured to determine the address of the service provider based on the service provider information, so as to send the interface call request to the service provider based on the address of the service provider.

[0147] In some embodiments, the apparatus further includes: a key and encryption algorithm receiving module, configured to receive keys and encryption algorithms corresponding to each sidecar container pre-issued by the security management system; and a key and encryption algorithm retrieval module, configured to retrieve the key and encryption algorithm corresponding to the sidecar container from the keys and encryption algorithms issued by the security management system based on the security node number of the sidecar container.

[0148] In some embodiments, the apparatus further includes: a security policy receiving module, configured to receive a security policy from a security management system; wherein the security policy is configured to instruct the steps of executing the interface call request processing method; and a security verification toolkit generation module, configured to package the interface executing the security policy according to the security policy to generate a security verification toolkit, so as to execute the interface call request processing method based on the security verification toolkit.

[0149] The interface call request processing device provided in this application embodiment can execute the communication fault handling method provided in this application embodiment, which is executed by the sidecar container of the service request end.

[0150] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software via processing element calls; they can be fully implemented in hardware; or some modules can be implemented by processing element calls to software, while others are implemented in hardware. For example, the interface call request receiving module 610 can be a separate processing element, or it can be integrated into a chip in the above device. Alternatively, it can be stored as program code in the memory of the above device, and its functions can be called and executed by a processing element of the above device. The implementation of other modules is similar. Moreover, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each of the above modules can be completed through integrated logic circuits in the hardware of the processor element or through software instructions.

[0151] Example 7

[0152] Figure 11 This is a schematic diagram of an interface call request processing device provided in Embodiment 7 of this application. This device can execute the interface call request processing method executed by the sidecar container of the service provider in this application. Figure 11 As shown, the device is configured in the electronic equipment corresponding to the sidecar container of the service provider, including: an interface call request parsing module 710, a verification information acquisition module 720, and a service request end verification module 730.

[0153] The interface call request parsing module 710 is used to receive the interface call request sent by the service requesting end and parse the interface call request.

[0154] The verification information acquisition module 720 is used to obtain verification information from the request header of the interface call request; wherein, the verification information is generated by the sidecar container of the service requesting end encrypting the identification information and security node number of the service requesting end according to the key and encryption algorithm;

[0155] The service request verification module 730 is used to verify the service request based on the verification information.

[0156] In some embodiments, the service request end verification module 730 verifies the service request end based on the verification information, specifically including: verifying the server request end's identity based on the key and encryption algorithm pre-issued by the security management system and the verification information; and verifying the service request end's interface call permissions based on the identification information in the verification information.

[0157] In some embodiments, the authentication of the server requesting party is performed based on the verification information according to the key and encryption algorithm pre-issued by the security management system, including: decrypting the verification information according to the key pre-issued by the security management system and the decryption algorithm corresponding to the encryption algorithm; and verifying the signature data portion of the verification information according to the identification information and the security node number in the payload data portion of the verification information.

[0158] In some embodiments, verifying the signature data portion of the verification information based on the identification information and the security node number in the payload data portion of the verification information includes: retrieving the key and the encryption algorithm corresponding to the sidecar container of the service requesting end from the key and the encryption algorithm issued by the security management system based on the security node number; signing the identification information and the security node number in the payload data portion of the verification information based on the key and the encryption algorithm; and comparing the signed result with the signature data portion of the verification information to verify the signature data portion of the verification information.

[0159] In some embodiments, verifying the interface call permission of the service requesting end based on the identification information in the verification information includes: obtaining the identification information from the payload data portion of the verification information; and determining whether the service requesting end has interface call permission based on the permission configuration information sent by the grid server and the identification information.

[0160] In some embodiments, after determining whether the service requester has interface call permissions based on the permission configuration information sent by the grid server and the identification information, the method further includes: if the service requester has interface call permissions, then sending the interface call request to the application container in the container group where the sidecar container is located, so that the application container can process the interface call request.

[0161] The interface call request processing device provided in this application embodiment can execute the interface call request processing method provided in this application embodiment, which is executed by the sidecar container of the service provider.

[0162] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software via processing element calls; they can be fully implemented in hardware; or some modules can be implemented by processing element calls to software, while others are implemented in hardware. For example, the interface call request parsing module 710 can be a separate processing element, or it can be integrated into a chip in the above device. Alternatively, it can be stored as program code in the memory of the above device, and its functions can be called and executed by a processing element of the above device. The implementation of other modules is similar. Moreover, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each of the above modules can be completed through integrated logic circuits in the hardware of the processor element or through software instructions.

[0163] Example 8

[0164] Figure 12 This is a schematic diagram of an interface call request processing device provided in Embodiment 8 of this application. This device can execute the interface call request processing method executed by the security policy management center in this application. Figure 12 As shown, the device is configured in the electronic equipment corresponding to the security policy management center, including: a permission configuration information type determination module 810, a permission configuration information generation module 820, and a permission configuration information synchronization module 830;

[0165] The permission configuration information type determination module 810 is used to determine the type of permission configuration information for an interface that requires permission configuration; wherein, the type of permission configuration information includes the type of service request client that is allowed to call the interface or the type of service request client that is not allowed to call the interface.

[0166] The permission configuration information generation module 820 is used to determine the service request end according to the type of the permission configuration information, and generate permission configuration information according to the interface and the corresponding service request end;

[0167] The permission configuration information synchronization module 830 is used to synchronize the permission configuration information to the grid server. The grid server sends the permission configuration information to the sidecar containers in each container group, so that the sidecar containers can parse the request header in the interface call request to obtain the verification information, and then process the interface call request according to the permission configuration information and the verification information.

[0168] The verification information is generated by the sidecar container of the service requesting end encrypting the identification information and security node number of the service requesting end according to the key and encryption algorithm; the key and the encryption algorithm are pre-distributed to the sidecar containers of each container group by the security management system.

[0169] In some embodiments, the permission configuration information generation module 820 generates permission configuration information based on the interface and the corresponding service request terminal, specifically including: creating a filter template based on the permission configuration information, and binding the filter template to a preset container group to create a filter for the permission configuration information.

[0170] In some embodiments, the permission configuration information synchronization module 830 synchronizes the permission configuration information to the grid server, and the grid server distributes the permission configuration information to the sidecar containers in each container group, so that the sidecar containers can process interface call requests according to the permission configuration information. This includes: for each combination of application, component, service and interface, determining the permission configuration information corresponding to the combination according to the type of the permission configuration information; synchronizing the permission configuration information corresponding to each combination to the grid server, so that the grid server distributes the permission configuration information corresponding to each combination to the service provider that provides the service corresponding to the combination.

[0171] In some embodiments, the apparatus further includes: an interface collection module, configured to collect all interfaces that can be provided by all container groups through the mesh server; and an interface determination module, configured to determine the interfaces that need to be configured with permissions in response to the user's interface selection operation on the visual interface of the security policy management center.

[0172] In some embodiments, the permission configuration information generation module 820 determines the service request end based on the type of the permission configuration information, and generates permission configuration information based on the interface and the corresponding service request end, including: if the type of the permission configuration information is a type of service request end that is allowed to call the interface, then determining the service request end that is allowed to access the interface; associating the interface with the identification information of the service request end that is allowed to access the interface, generating permission configuration information, so that the sidecar container determines that the service request end has access to the corresponding interface when it determines that the identification information of the service request end belongs to the permission configuration information.

[0173] In some embodiments, the permission configuration information generation module 820 determines the service request end based on the type of the permission configuration information, and generates permission configuration information based on the interface and the corresponding service request end, including: if the type of the permission configuration information is a type of service request end that is not allowed to call the interface, then the service request end that is not allowed to access the interface is determined, or the service request ends that are allowed to access the interface are removed from all service request ends to obtain the service request ends that are not allowed to access the interface; the interface is associated with the identification information of the service request end that is not allowed to access the interface to generate permission configuration information, so that the sidecar container determines that the service request end has access to the corresponding interface when it determines that the identification information of the service request end does not belong to the identification information corresponding to the interface in the permission configuration information.

[0174] The interface call request processing device provided in this application embodiment can execute the interface call request processing method provided in this application embodiment, which is executed by the security policy management center.

[0175] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software via processing element calls; they can be fully implemented in hardware; or some modules can be implemented by processing element calls to software, while others are implemented in hardware. For example, the permission configuration information type determination module 810 can be a separate processing element, or it can be integrated into a chip in the above device. Alternatively, it can be stored as program code in the memory of the above device, and its function can be called and executed by a processing element of the above device. The implementation of other modules is similar. Moreover, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each of the above modules can be completed through integrated logic circuits in the hardware of the processor element or through software instructions.

[0176] Example 9

[0177] Figure 13 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 13 As shown, the electronic device may include: transceiver 121, processor 122, and memory 123.

[0178] Processor 122 executes computer execution instructions stored in memory, causing processor 122 to perform the scheme in the above embodiments. Processor 122 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0179] The memory 123 is connected to the processor 122 via the system bus and completes communication between them. The memory 123 is used to store computer program instructions.

[0180] Transceiver 121 can be used to obtain the task to be run and its configuration information.

[0181] The system bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the diagram, but this does not indicate that there is only one bus or one type of bus. Transceivers are used to enable communication between database access devices and other computers (e.g., clients, read-write libraries, and read-only libraries). Memory may include random access memory (RAM) and may also include non-volatile memory.

[0182] The electronic device provided in this application embodiment can be the terminal device described in the above embodiments.

[0183] This application also provides a chip for executing instructions, which is used to execute the technical solution of the interface call request processing method in the above embodiments.

[0184] This application also provides a computer-readable storage medium storing computer instructions that, when executed on a computer, cause the computer to perform the technical solution of the interface call request processing method described above.

[0185] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium. When the at least one processor executes the computer program, it can implement the technical solution of the interface call request processing method in the above embodiments.

[0186] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0187] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for processing interface call requests, characterized in that, Executed by the sidecar container of the service requester, including: Receive the interface call request sent by the application container in the container group where the sidecar container is located; Based on the key and encryption algorithm, the identification information and security node number of the service requesting end are encrypted to generate verification information; wherein, the key and the encryption algorithm are pre-distributed to the sidecar containers of each container group by the security management system; The verification information is used as the request header of the interface call request and sent to the service provider so that the service provider can parse the request header in the interface call request to obtain the verification information and perform security verification on the service requesting end.

2. The method according to claim 1, characterized in that, Based on the key and encryption algorithm, the identification information and security node number of the service requesting client are encrypted to generate verification information, including: Generate the header data portion of the verification information according to the type of the verification information; The payload data portion of the verification information is generated based on the identification information and the security node number. The identification information and the security node number are signed according to the key and encryption algorithm to generate the signature data part of the verification information.

3. The method according to claim 1, characterized in that, The method further includes: Establish communication with the grid server via a long-lived connection; The system receives permission configuration information sent by the grid server to determine whether the application sending the interface call request to the service requester has access permissions based on the permission configuration information.

4. The method according to claim 1, characterized in that, After receiving the interface call request sent by the application container in the container group where the sidecar container is located, the method further includes: Obtain information about the service provider in the interface call request; The address of the service provider is determined based on the information of the service provider, and the interface call request is sent to the service provider based on the address of the service provider.

5. The method according to claim 1, characterized in that, Before encrypting the identification information and security node number of the service requesting client according to the key and encryption algorithm to generate verification information, the method further includes: Receive the keys and encryption algorithms corresponding to each sidecar container pre-issued by the security management system; Based on the security node number of the sidecar container, the key and encryption algorithm corresponding to the sidecar container are retrieved from the keys and encryption algorithms issued by the security management system.

6. The method according to claim 1, characterized in that, Before encrypting the identification information and security node number of the service requesting client according to the key and encryption algorithm to generate verification information, the method further includes: Receive a security policy from the security management system; wherein the security policy is used to instruct the steps of executing the interface call request processing method; According to the security policy, the interface that executes the security policy is packaged to generate a security verification toolkit, and the interface call request processing method is executed based on the security verification toolkit.

7. A method for handling interface call requests, characterized in that, Executed by the sidecar container of the service provider, including: Receive the interface call request sent by the service request client, and parse the interface call request; The verification information is obtained from the request header of the interface call request; wherein, the verification information is generated by the sidecar container of the service requesting end by encrypting the identification information and security node number of the service requesting end according to the key and encryption algorithm; The service requesting client is verified based on the verification information.

8. The method according to claim 7, characterized in that, The service requester is verified based on the verification information, including: Based on the keys and encryption algorithms pre-issued by the security management system, the service requester is authenticated according to the verification information. The interface call permissions of the service requesting end are verified based on the identification information in the verification information.

9. The method according to claim 8, characterized in that, Based on the keys and encryption algorithms pre-issued by the security management system, the service requester is authenticated according to the verification information, including: The verification information is decrypted based on the key pre-issued by the security management system and the decryption algorithm corresponding to the encryption algorithm; The signature data portion of the verification information is verified based on the identification information and the security node number in the payload data portion of the verification information.

10. The method according to claim 9, characterized in that, The signature data portion of the verification information is verified based on the identification information and the security node number in the payload data portion of the verification information, including: Based on the security node number, retrieve the key and encryption algorithm corresponding to the sidecar container of the service requesting end from the key issued by the security management system and the encryption algorithm; Based on the key and the encryption algorithm, the identification information and the security node number in the payload data portion of the verification information are signed; The signed result is compared with the signature data portion of the verification information to verify the signature data portion of the verification information.

11. The method according to claim 8, characterized in that, Based on the identification information in the verification information, the interface call permissions of the service requesting client are verified, including: The identification information is obtained from the payload data portion of the verification information; Based on the permission configuration information sent by the grid server and the identification information, it is determined whether the service requesting end has interface call permissions.

12. The method according to claim 11, characterized in that, After determining whether the service requesting client has interface call permissions based on the permission configuration information sent by the grid server and the identification information, the method further includes: If the service requesting end has interface call permission, then the interface call request is sent to the application container in the container group where the sidecar container is located, so that the application container can process the interface call request.

13. A method for processing interface call requests, characterized in that, The method, executed by the security policy management center, includes: For interfaces that require permission configuration, determine the type of permission configuration information; wherein, the type of permission configuration information includes the type of service request client that is allowed to call the interface or the type of service request client that is not allowed to call the interface; The service request client is determined based on the type of the permission configuration information, and permission configuration information is generated based on the interface and the corresponding service request client. The permission configuration information is synchronized to the grid server, and the grid server distributes the permission configuration information to the sidecar containers in each container group, so that the sidecar containers can parse the request header in the interface call request to obtain the verification information, and then process the interface call request according to the permission configuration information and the verification information. The verification information is generated by the sidecar container of the service requesting end encrypting the identification information and security node number of the service requesting end according to the key and encryption algorithm; the key and the encryption algorithm are pre-distributed to the sidecar containers of each container group by the security management system.

14. The method according to claim 13, characterized in that, Based on the interface and the corresponding service request client, permission configuration information is generated, including: A filter template is created based on the permission configuration information, and the filter template is bound to a preset container group to create a filter based on the permission configuration information.

15. The method according to claim 13, characterized in that, Synchronize the permission configuration information to the grid server, including: For each combination of applications, components, services, and interfaces, the corresponding permission configuration information is determined based on the type of the permission configuration information. The permission configuration information corresponding to each combination is synchronized to the grid server, so that the grid server can distribute the permission configuration information corresponding to each combination to the service provider that provides the service corresponding to that combination.

16. The method according to claim 13, characterized in that, Before determining the type of permission configuration information for the interface requiring permission configuration, the method further includes: The grid server collects all interfaces that all container groups can provide; In response to the user's interface selection operation on the visual interface of the security policy management center, determine the interface that needs permission configuration.

17. The method according to claim 13, characterized in that, The service request client is determined based on the type of the permission configuration information, and permission configuration information is generated based on the interface and the corresponding service request client, including: If the type of the permission configuration information reflects the type of service request client allowed to call the interface, then the service request client allowed to access the interface is determined. The interface is associated with the identification information of the service request client that is allowed to access the interface, and permission configuration information is generated so that the side vehicle container can determine that the service request client has access to the corresponding interface if the identification information of the service request client belongs to the permission configuration information.

18. The method according to claim 13, characterized in that, The service request client is determined based on the type of the permission configuration information, and permission configuration information is generated based on the interface and the corresponding service request client, including: If the type of the permission configuration information is a type of service request client that is allowed to call the interface, then the service request clients that are not allowed to access the interface are determined, or the service request clients that are allowed to access the interface are removed from all the service request clients to obtain the service request clients that are not allowed to access the interface. The interface is associated with the identification information of the service request client that is not allowed to access the interface, and permission configuration information is generated so that the side vehicle container can determine that the service request client has access to the corresponding interface if the identification information of the service request client does not belong to the identification information corresponding to the interface in the permission configuration information.

19. An interface call request processing device, characterized in that, The electronic devices corresponding to the sidecar container configured on the service request end include: The interface call request receiving module is used to receive interface call requests sent by the application container in the container group where the sidecar container is located; The verification information generation module is used to encrypt the identification information and security node number of the service requesting end according to the key and encryption algorithm to generate verification information; wherein, the key and the encryption algorithm are pre-distributed to the sidecar containers of each container group by the security management system; The interface call request sending module is used to send the verification information as the request header of the interface call request to the service provider, so that the service provider can parse the request header in the interface call request to obtain the verification information and perform security verification on the service requesting end.

20. An interface call request processing device, characterized in that, The electronic devices corresponding to the sidecar container configured on the service provider side include: The interface call request parsing module is used to receive interface call requests sent by the service request client and parse the interface call requests. The verification information acquisition module is used to obtain verification information from the request header of the interface call request; wherein, the verification information is generated by the sidecar container of the service requesting end encrypting the identification information and security node number of the service requesting end according to the key and encryption algorithm; The service request verification module is used to verify the service request based on the verification information.

21. An interface call request processing device, characterized in that, The electronic devices configured in the security policy management center include: The permission configuration information type determination module is used to determine the type of permission configuration information for interfaces that require permission configuration; wherein, the type of permission configuration information includes the type of service request client that is allowed to call the interface or the type of service request client that is not allowed to call the interface; The permission configuration information generation module is used to determine the service request end according to the type of the permission configuration information, and generate permission configuration information according to the interface and the corresponding service request end; The permission configuration information synchronization module is used to synchronize the permission configuration information to the grid server. The grid server then sends the permission configuration information to the sidecar containers in each container group, so that the sidecar containers can parse the request header in the interface call request to obtain the verification information, and then process the interface call request according to the permission configuration information and the verification information. The verification information is generated by the sidecar container of the service requesting end encrypting the identification information and security node number of the service requesting end according to the key and encryption algorithm; the key and the encryption algorithm are pre-distributed to the sidecar containers of each container group by the security management system.

22. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes the computer execution instructions stored in the memory to implement the interface call request processing method executed by the sidecar container of the service requesting end as described in any one of claims 1-6, or to implement the interface call request processing method executed by the sidecar container of the service providing end as described in any one of claims 7-12, or to implement the interface call request processing method executed by the security policy management center as described in any one of claims 13-18.

23. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the interface call request processing method executed by the sidecar container of the service requesting end as described in any one of claims 1-6, or to implement the interface call request processing method executed by the sidecar container of the service providing end as described in any one of claims 7-12, or to implement the interface call request processing method executed by the security policy management center as described in any one of claims 13-18.

24. A computer program product, characterized in that, The computer program, when executed by a processor, implements the interface call request processing method executed by the sidecar container of the service requesting end as described in any one of claims 1-6, or implements the interface call request processing method executed by the sidecar container of the service providing end as described in any one of claims 7-12, or implements the interface call request processing method executed by the security policy management center as described in any one of claims 13-18.

Images