Service communication method and device and electronic equipment

Abstract

The invention relates to a service communication method and device and electronic equipment, and the method comprises the steps: responding to a bidirectional authentication encryption channel building request initiated between a non-grid service and a grid service, and building a bidirectional authentication encryption channel between the non-grid service and the grid service; wherein a service grid agent of the grid service is configured to support an application layer protocol used by a non-grid service; and in response to a bidirectional authentication encryption channel establishment request initiated between the first object and the second object, establishing a bidirectional authentication encryption channel between the first object and the second object. Therefore, zero-trust security reinforcement of full-scene communication is realized, and a compatible and secure communication environment is provided for all services in the cluster.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of network security, and in particular to a service communication method and device, electronic equipment and a storage medium. BACKGROUND

[0002] Zero trust is a new network security paradigm that focuses on resource protection, and its core principle is that everything is insecure and must be verified.

[0003] In a service cloud infrastructure, such as a service mesh, multiple types of traffic are involved, including external traffic (north-south traffic, such as client access to the server), internal traffic (such as cluster or cross-cluster service communication), and export traffic (such as cluster internal service access to the outside). Under the security paradigm of zero trust, external traffic uses security certificates for mTLS (mutual Transport Layer Security) encrypted communication, and identity information is parsed through JWT (JSON Web Token), to ensure the confidentiality of communication and the traceability of identity; internal traffic uses the mTLS encryption mechanism of the service mesh, and identity is passed through SAN (Subject Alternative Name) in the TLS (Transport Layer Security) handshake process, to ensure the security and reliability of internal service communication; export traffic is encrypted through a unified export gateway mTLS, and SAN or JWT can be flexibly added for identity verification, to ensure the legality and security of external access.

[0004] However, during the transition from traditional services to service meshes, due to the lack of compatible mTLS protocol support between non-mesh services and mesh services, non-mesh service requests for mesh services will reset the connection in the TLS handshake phase, and mesh service requests for non-mesh services also do not use mTLS by default, thereby breaking the zero trust security paradigm and posing a security risk. At the same time, there is a security risk in external traffic entering through the gateway. Although the external traffic entering through the gateway is encrypted with TLS, the gateway forwards the internal service in plaintext after unloading the certificate, and the external certificate cannot be used for internal traffic encryption, resulting in no encryption protection for internal traffic and posing a security risk. SUMMARY

[0005] The present application provides a service communication method, device and electronic equipment to solve the technical problems of non-mesh services and mesh services being unable to establish bidirectional authentication and encryption communication due to incompatible communication protocols during the transition from traditional services to service meshes, breaking the zero trust security paradigm, and the gateway unloading certificates resulting in no encryption protection for north-south traffic.

[0006] In a first aspect, the present application provides a service communication method, the method comprising: In response to initiating a bidirectional authentication encrypted channel establishment request between a non-grid service and a grid service, establishing a first bidirectional authentication encrypted channel between the non-grid service and the grid service; wherein a service grid agent of the grid service is configured to support an application layer protocol used by the non-grid service; In response to initiating a bidirectional authentication encrypted channel establishment request between a first object and a second object, establishing a second bidirectional authentication encrypted channel between the first object and the second object.

[0007] In a possible implementation, the service grid agent of the grid service is configured to support the application layer protocol used by the non-grid service by: Registering a service address of the non-grid service to a service discovery mechanism of the grid service, so that the grid service discovers the non-grid service; Based on the service address registration information of the non-grid service, extending a set of application layer protocol identifiers supported by the service grid agent, so that an application layer protocol identifier used by the non-grid service is included in the set of application layer protocol identifiers; Hot loading the extended set of application layer protocol identifiers to the service grid agent.

[0008] In a possible implementation, the method further comprises: In the case where it is detected that a transport layer security protocol of the grid service and the non-grid service changes, updating the set of application layer protocol identifiers supported by the service grid agent, so that an updated set of application layer protocol identifiers is adapted to the changed transport layer security protocol; The service grid agent applies the updated set of application layer protocol identifiers by hot loading.

[0009] In a possible implementation, the change of the transport layer security protocol of the grid service and the non-grid service comprises: The communication protocol of the grid service and the non-grid service changes from a bidirectional authentication transport layer security protocol to a unidirectional authentication transport layer security protocol, or from a unidirectional authentication transport layer security protocol to a bidirectional authentication transport layer security protocol; The updating of the set of application layer protocol identifiers supported by the service grid agent comprises: In the case where the transport layer security protocol changes from a bidirectional authentication transport layer security protocol to a unidirectional authentication transport layer security protocol, removing an application layer protocol identifier in the set of application layer protocol identifiers supported by the service grid agent, which is used to trigger a bidirectional authentication process; In a case that the communication protocol is changed from a one-way authentication transport layer security protocol to a two-way authentication transport layer security protocol, an application layer protocol identifier for triggering a two-way authentication process is added in a set of application layer protocol identifiers supported by the service mesh proxy.

[0010] In a possible implementation, the method further includes: issuing, by a zero trust proxy client deployed in the cluster, internal two-way authentication certificates to gateways and non-mesh services in the cluster to establish a second two-way authentication encrypted channel between the first object and the second object based on the internal two-way authentication certificates.

[0011] In a possible implementation, the method further includes: requesting, at a preset period, a certificate authority to generate a new internal two-way authentication certificate, and distributing, by the zero trust proxy client, the new internal two-way authentication certificate to the gateways and non-mesh services in the cluster.

[0012] In a possible implementation, the method further includes: in a case that the internal two-way authentication certificate is detected to be leaked, sending a certificate revocation request to a certificate authority, and requesting the certificate authority to generate a new internal two-way authentication certificate; distributing, by the zero trust proxy client, the new internal two-way authentication certificate to the gateways and non-mesh services in the cluster.

[0013] In a possible implementation, the method further includes: in a case that the validity period of the internal two-way authentication certificate is monitored to be expired, requesting a certificate authority to generate a new internal two-way authentication certificate, and distributing, by the zero trust proxy client, the new internal two-way authentication certificate to the gateways and non-mesh services in the cluster.

[0014] In a possible implementation, the distributing, by the zero trust proxy client, the new internal two-way authentication certificate to the gateways and non-mesh services in the cluster includes: the zero trust proxy client synchronously distributes the new internal two-way authentication certificate to each receiving object in the cluster, and monitors a certificate receiving state of each receiving object; in a case that each receiving object is confirmed to successfully receive the new internal two-way authentication certificate, the zero trust proxy client sends a certificate enabling instruction to each receiving object respectively, so that each receiving object respectively configures the new internal two-way authentication certificate to an effective state.

[0015] In a possible implementation, the method further includes: In a case where any of the receiving objects fails to receive the new internal mutual authentication certificate, the zero-trust proxy client terminates the current certificate distribution process, and each of the receiving objects maintains the original certificate state.

[0016] In a possible implementation, the method further includes: issuing, by a zero-trust proxy client deployed in the cluster, internal mutual authentication certificates to gateways and non-mesh services in the cluster; The zero-trust proxy client establishes a local secure communication channel with each of the gateways and the non-mesh services, and distributes the internal mutual authentication certificates to the gateways and the non-mesh services in the cluster through the local secure communication channel.

[0017] In a second aspect, the present application provides a service communication device, the device comprising: a first mutual authentication encryption module configured to establish a first mutual authentication encryption channel between a non-mesh service and a mesh service in response to a request for establishing the first mutual authentication encryption channel initiated between the non-mesh service and the mesh service; and a second mutual authentication encryption module configured to establish a second mutual authentication encryption channel between a first object and a second object in response to a request for establishing the second mutual authentication encryption channel initiated between the first object and the second object.

[0018] In a possible implementation, the device further includes: a configuration module configured to configure a service mesh proxy of the mesh service to support an application layer protocol used by a non-mesh service in the cluster; The service address of the non-mesh service is registered to a service discovery mechanism of the mesh service, so that the mesh service discovers the non-mesh service; Based on the service address registration information of the non-mesh service, the set of application layer protocol identifiers supported by the service mesh proxy is extended, so that the application layer protocol identifier used by the non-mesh service is included in the set of application layer protocol identifiers; The extended set of application layer protocol identifiers is hot-loaded to the service mesh proxy.

[0019] In a possible implementation, the device further includes: a dynamic update module configured to, in a case where a change occurs in a transport layer security protocol of the mesh service and the non-mesh service, update the set of application layer protocol identifiers supported by the service mesh proxy, so that the updated set of application layer protocol identifiers is adapted to the changed transport layer security protocol; The service mesh proxy applies the updated set of application layer protocol identifiers via hot reloading.

[0020] In one possible implementation, the transport layer security protocols for the mesh service and the non-mesh service are modified, including: The communication protocol between grid services and non-grid services is changed from a two-way authentication transport layer security protocol to a one-way authentication transport layer security protocol, or from a one-way authentication transport layer security protocol to a two-way authentication transport layer security protocol. The dynamic update module updates the set of application layer protocol identifiers supported by the service mesh proxy, including: When the transport layer security protocol is changed from a two-way authentication transport layer security protocol to a one-way authentication transport layer security protocol, remove the application layer protocol identifiers used to trigger the two-way authentication process from the application layer protocol identifier set supported by the service mesh proxy. When the communication protocol is changed from a one-way authentication transport layer security protocol to a two-way authentication transport layer security protocol, an application layer protocol identifier for triggering the two-way authentication process is added to the set of application layer protocol identifiers supported by the service mesh agent.

[0021] In one possible implementation, the device further includes: The certificate issuance module is used to issue internal two-way authentication certificates to the gateway and non-mesh service in the cluster through the zero-trust proxy client deployed in the cluster, so as to establish a second two-way authentication encrypted channel between the first object and the second object based on the internal two-way authentication certificate.

[0022] In one possible implementation, the device further includes: The certificate rotation module is used to request the generation of new internal two-way authentication certificates from the certificate authority according to a preset period, and distribute the new internal two-way authentication certificates to the gateways and non-mesh services in the cluster through the zero-trust proxy client.

[0023] In one possible implementation, the device further includes: The certificate update module is used to send a certificate revocation request to the certificate authority and request the certificate authority to generate a new internal two-way authentication certificate when the leakage of the internal two-way authentication certificate is detected; and to distribute the new internal two-way authentication certificate to the gateway and non-mesh service in the cluster through the zero-trust proxy client.

[0024] In one possible implementation, the device further includes: The certificate updating module is configured to request a certificate authority to generate a new internal mutual authentication certificate when it is detected that the validity period of the internal mutual authentication certificate expires, and distribute the new internal mutual authentication certificate to the gateway and the non-grid service in the cluster via the zero-trust proxy client.

[0025] In a possible implementation, the certificate updating module distributes the new internal mutual authentication certificate to the gateway and the non-grid service in the cluster via the zero-trust proxy client, including: The zero-trust proxy client synchronously distributes the new internal mutual authentication certificate to each receiving object in the cluster, and monitors the certificate receiving status of each receiving object. When it is confirmed that each receiving object successfully receives the new internal mutual authentication certificate, the zero-trust proxy client sends a certificate enabling instruction to each receiving object, so that each receiving object configures the new internal mutual authentication certificate to an effective state.

[0026] In a possible implementation, the certificate updating module is further configured to: When it is detected that any receiving object fails to receive the new internal mutual authentication certificate, the zero-trust proxy client terminates the current certificate distribution process, and each receiving object maintains the original certificate state.

[0027] In a possible implementation, the apparatus further includes: A certificate issuing module is configured to issue an internal mutual authentication certificate to the gateway and the non-grid service in the cluster via the zero-trust proxy client deployed in the cluster. The zero-trust proxy client and the gateway and the non-grid service establish a local secure communication channel between each other, and distribute the internal mutual authentication certificate to the gateway and the non-grid service in the cluster via the local secure communication channel.

[0028] In a third aspect, the present application provides an electronic device, including a processor and a memory, the processor is configured to execute a service communication program stored in the memory to implement the service communication method in any one of the first aspect.

[0029] In a fourth aspect, the present application provides a storage medium, the storage medium stores one or more programs, the one or more programs can be executed by one or more processors to implement the service communication method in any one of the first aspect.

[0030] Compared with the prior art, the technical scheme provided by the embodiment of the present application has the following advantages: the method provided by the embodiment of the present application configures the service mesh agent of the mesh service in the cluster to support the application layer protocol used by the non-mesh service, expands the application layer protocol support capability of the service mesh agent, makes it compatible with the internal protocol of the service mesh and the external protocol of the service mesh, thereby solving the communication protocol compatibility problem of cross-type services, and further constructing a first bidirectional authentication encryption channel between the non-mesh service and the mesh service; at the same time, a second bidirectional authentication encryption channel is established between the two communication objects (including the non-mesh service, the gateway and the target service), effectively eliminating the security risks of internal traffic plaintext transmission and non-mesh service communication without encryption. The technical scheme uses two types of bidirectional authentication encryption channels, which not only guarantees the protocol interworking under the hybrid service architecture, but also realizes the zero-trust security reinforcement of all-scene communication, and can resist network attacks such as eavesdropping, tampering and identity forgery, thereby providing a compatible and secure communication environment for all services in the cluster. BRIEF DESCRIPTION OF DRAWINGS

[0031] The accompanying drawings, which are incorporated into and form part of the specification, illustrate embodiments consistent with the present application and, together with the specification, serve to explain the principles of the application.

[0032] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiment or prior art description will be briefly introduced below. Obviously, for those skilled in the art, other drawings can also be obtained without creative labor based on these drawings.

[0033] One or more embodiments are exemplarily illustrated by pictures in the drawings corresponding thereto, and these exemplary illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, unless otherwise specified. The drawings in the drawings do not constitute a proportional limitation.

[0034] Figure 1 An embodiment flowchart of a service communication method provided by the embodiment of the present application; Figure 2 An embodiment flowchart of another service communication method provided by the embodiment of the present application; Figure 3 An embodiment block diagram of a service communication device provided by the embodiment of the present application; Figure 4 A structural schematic diagram of an electronic device provided by the embodiment of the present application. DETAILED DESCRIPTION

[0035] To make the objectives, technical solutions, and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described below in a clear and complete manner with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0036] The following disclosure provides many different embodiments or examples for implementing different structures of the present application. In order to simplify the disclosure of the present application, the components and arrangements of specific examples are described below. Of course, they are only examples and the purpose is not to limit the present application. In addition, reference numerals and / or letters can be repeated in different examples in the present application. Such repetition is for the purpose of simplification and clarity, and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0037] In order to solve the technical problems in the prior art that during the transition of traditional services to a service mesh, non-mesh services and mesh services cannot establish bidirectional authentication and encryption communication due to incompatible communication protocols, the zero-trust security paradigm is destroyed, and the gateway offloads certificates, resulting in no encryption protection for north-south traffic, the present application provides a service communication method and device, electronic equipment and storage medium, to realize zero-trust security reinforcement for full-scene communication, and can resist network attacks such as eavesdropping, tampering, and identity forgery, thereby providing a compatible and secure communication environment for all services in the cluster.

[0038] For ease of understanding, the following first exemplarily explains the concepts and scenarios involved in the technical solutions of the present application: A cluster is a collection of a group of interconnected and communication-capable computer nodes (which can be physical servers, virtual machines, or container instances) that work together through a network to collectively provide various services. In the application scenario of the embodiments of the present application, the cluster is the basic environment for service running, and provides physical and logical support for the stable operation of the entire system.

[0039] With the continuous expansion of the cluster size and the continuous improvement of the business complexity, the communication relationship between services in the cluster becomes increasingly complex. Under this background, a service mesh emerges as a kind of infrastructure specially processing the communication problems between services, tightly connecting the services in the cluster, and finely and comprehensively managing and controlling the communication between services. The service mesh can endow application programs with a series of key capabilities without intruding into the business code. The embodiments of the present application focus on the zero-trust security capability: by adopting a zero-trust security model, strict identity verification and authorization are implemented for the communication between services, so as to ensure that only legitimate service parties can intercommunicate, and effectively prevent data leakage and malicious attacks.

[0040] Take Istio as an example, it is an open source service mesh project. Istio provides a complete and mature solution for building and managing service mesh, and there is a close and indispensable relationship between the cluster and the service mesh. Istio has excellent compatibility and integration capabilities, and can seamlessly adapt and integrate into various types of cluster environments. Whether it is the currently widely used Kubernetes cluster, Docker Swarm cluster, or other types of container orchestration platforms, Istio can provide consistent and high-quality service mesh experience. It manages service communication effectively by deploying a series of well-designed components in the cluster, including the control plane component istiod and the data plane component envoy (i.e. service mesh proxy).

[0041] In the control plane, the control plane component istiod is responsible for formulating communication strategies and configuration rules, and issuing these configuration information to each envoy proxy in the data plane. In the data plane, envoy proxy acts as the direct handler of service communication, responsible for intercepting and processing all communication traffic between services. According to the strategy issued by the control plane, envoy proxy carries out traffic management, security authentication and other operations in an orderly manner, ensuring that service communication meets the predetermined rules and requirements.

[0042] For example, in an Istio-based cluster environment, when a new service is deployed to the cluster, Istio will start the automated management process and automatically inject envoy proxy for the service, providing communication management tools for the new service. At the same time, istiod customizes the communication strategy for the service, thus achieving comprehensive and fine-grained management of the new service communication. This process ensures that all service communication in the cluster can be carried out efficiently, securely and orderly under the specification of the Istio service mesh, providing strong support for the stable operation of the entire distributed system.

[0043] Mesh service refers to services that access the service mesh (such as Istio). After business services access Istio, Istio will automatically convert internal calls to mTLS encrypted communication to ensure the security of service communication.

[0044] Non-mesh service refers to services that do not access the service mesh. In real business scenarios, due to various reasons, not all services will access the service mesh, and these services that do not access the service mesh are non-mesh services.

[0045] In a business scenario of transition from traditional services to a service mesh (for example, Istio), there are both mesh services and non-mesh services in the business system. After the business services access Istio, Istio automatically converts the calls within the mesh into mTLS encrypted communication to ensure the security of inter-service communication. However, there are differences between non-mesh services and mesh services in terms of communication protocol compatibility, which leads to the following problems: when the non-mesh service requests the mesh service through mTLS, the strict ALPN (Application Layer Protocol Negotiation) matching rule (which limits the protocol negotiated in the TLS handshake stage to be an internal protocol of Istio, such as istio, istio-peer-exchange, istio-http / 1.0, istio-http / 1.1, or istio-h2) is set in the mTLS processing configuration issued by istiod to the Envoy proxy, and the ALPN delivered by the non-mesh service is always the standard HTTP (HyperText Transfer Protocol) protocol (such as h2, http / 1.1, etc.), resulting in failure of protocol negotiation in the TLS handshake stage, and finally the connection is rejected by the Envoy proxy.

[0046] As can be seen, the root cause of the above problems is that the ALPN protocols followed by non-mesh services and mesh services are incompatible. To this end, in the embodiments of the present application, the service mesh proxy of the mesh service in the cluster is configured to support the application layer protocol used by the non-mesh service in the cluster. In this way, the incompatibility problem of non-mesh services and mesh services in ALPN matching can be eliminated, so that the non-mesh service can establish a normal mTLS connection with the mesh service, and the security of communication between the non-mesh service and the mesh service is ensured.

[0047] The specific principle is as follows: in the architecture of Istio, when calling a service that has accessed Istio (i.e., a mesh service), the traffic will first pass through the service mesh proxy Envoy. The service mesh proxy Envoy processes the request according to the configuration information issued by the control plane component istiod, and then forwards the processed request to the corresponding business service. In the process of processing mTLS requests, the service mesh proxy Envoy undertakes the key task of TLS handshake, which completes the decryption of encrypted traffic and forwards the decrypted traffic to the business service for subsequent processing. However, since the ALPN transmitted by non-mesh services is the standard HTTP protocol, and the ALPN matching rule set in the configuration of the service mesh proxy Envoy issued by istiod for processing mTLS requests only targets the internal protocol of Istio, this makes the TLS handshake process unable to be completed smoothly. By configuring the service mesh proxy Envoy to support the application layer protocol used by non-mesh services, such as modifying the ALPN matching rule of Istio to include standard HTTP protocols (such as h2, http / 1.1, etc.), the service mesh proxy Envoy proxy can correctly identify and process the TLS handshake request of non-mesh services, thereby successfully establishing a normal mTLS connection and ensuring smooth communication between non-mesh services and mesh services.

[0048] At the same time, in the business scenario of the transition of traditional services to the service mesh, when external users initiate requests to the gateway, although TLS encryption technology is used to protect the transmission data, to a certain extent, the security of the data during transmission in the external network is ensured. However, when the traffic arrives at the gateway, the gateway will perform a certificate offloading operation to decrypt the originally encrypted traffic into plaintext, and then forward it to the internal service in plaintext form. Moreover, the certificate used by external users is specifically designed for external communication and cannot be directly applied to the encryption process of internal traffic. This results in the internal traffic being in an unencrypted state, which is extremely vulnerable to eavesdropping, tampering, and other security attacks, posing a great risk to the stable operation of the system and the security of the data. In addition, there are similar security vulnerabilities in the traffic interaction between non-mesh services. When communicating between non-mesh services, there is a lack of effective identity authentication and encryption mechanisms, making it difficult for the communication parties to confirm the true identity of the other party and to encrypt the transmitted data. This makes the communication between non-mesh services vulnerable to man-in-the-middle attacks, data leakage, and other security threats. Once the attacker intercepts and tampers with the communication data, it may cause serious consequences such as business logic confusion, data errors, and even affect the normal operation of the entire business system.

[0049] Therefore, in the embodiments of the present application, a zero-trust proxy client is also deployed in the cluster to issue internal two-way authentication certificates to the gateway and non-mesh services in the cluster. This approach aims to solve the problems of insufficient security protection of internal traffic and communication security of non-mesh services from the root.

[0050] Specifically, the internal two-way authentication certificate contains the key identity information of the service and is protected by an encryption algorithm to ensure that it is difficult to be forged and tampered with. During service communication, the communication parties exchange and verify these certificates to achieve two-way identity authentication. Only after the identity verification is passed, a two-way encrypted communication connection is established to encrypt and protect the transmitted data. In this way, whether it is internal traffic entering through the gateway or communication traffic between non-mesh services, it can be transmitted safely and reliably under the protection of the zero-trust security architecture, effectively resisting various security threats.

[0051] It is worth noting that in a cluster environment, non-mesh services and gateways are often dynamic, such as frequent scaling, node migration, or adding / removing services, and such services are not connected to the unified management system of the service mesh, lacking built-in certificate receiving and management capabilities. At the same time, as the core security credential, the internal two-way authentication certificate needs to be strictly protected in terms of confidentiality and directionality during distribution to avoid leakage or unauthorized access. Therefore, in the technical solutions provided by the embodiments of the present application, a zero-trust proxy client is deployed in the cluster to issue internal two-way authentication certificates to the gateway and non-mesh services in the cluster. On the one hand, the zero-trust proxy client can use the cluster service discovery mechanism to real-time perceive the existence and location of non-mesh services and gateways, ensuring that newly online services can be identified and included in the certificate management range in time, avoiding incomplete certificate coverage due to dynamic service changes; on the other hand, the zero-trust proxy client can establish a private connection with the target service through a local secure communication channel (such as a Unix domain socket) to avoid plaintext exposure during certificate transmission and verify the service identity of the receiver to ensure that the certificate is only distributed to authorized objects. In an embodiment, the zero-trust proxy client issues internal two-way authentication certificates to the gateway and non-mesh services in the cluster by establishing a local secure communication channel, such as a Unix domain socket, between the zero-trust proxy client and the gateway and non-mesh services. Then, the zero-trust proxy client distributes the internal two-way authentication certificates to the gateway and non-mesh services in the cluster through the local secure communication channel.

[0052] Based on the above description, referring to Figure 1 , an embodiment flowchart of a service communication method provided by the embodiments of the present application is shown. As Figure 1 shown, the flowchart includes the following steps: Step 101, in response to initiating a bidirectional authentication encryption channel establishment request between the non-mesh service and the mesh service, establishing a first bidirectional authentication encryption channel between the non-mesh service and the mesh service; and, in response to initiating a bidirectional authentication encryption channel establishment request between the first object and the second object, establishing a second bidirectional authentication encryption channel between the first object and the second object.

[0053] Step 101 involves the security and compatibility of service communication in different scenarios, which will be discussed as follows: Case one, establishing a first bidirectional authentication encryption channel between the non-mesh service and the mesh service.

[0054] When any one of the non-mesh service and the mesh service initiates a bidirectional authentication encryption channel establishment request to the other party (for example, the non-mesh service initiates a bidirectional authentication encryption channel establishment request to the mesh service, or the mesh service initiates a bidirectional authentication encryption channel establishment request to the non-mesh service), a first bidirectional authentication encryption channel is established between the non-mesh service and the mesh service based on the pre-configured "service mesh proxy supports the application layer protocol of the non-mesh service".

[0055] Specifically, if the bidirectional authentication encryption channel establishment request is initiated by the non-mesh service, the non-mesh service generates a TLS handshake request containing the application layer protocol identifier (such as h2, http / 1.1, etc. of the standard HTTP protocol) used by itself. After receiving the TLS handshake request, the service mesh proxy of the mesh service negotiates the protocol with the non-mesh service according to the application layer protocol it supports. Since the service mesh proxy has supported the application layer protocol used by the non-mesh service at this time, there is no compatibility problem in the ALPN matching in the TLS handshake stage, and both parties can successfully complete identity authentication (including legality verification based on service identity). After authentication, a first bidirectional authentication encryption channel is established, and the traffic between the non-mesh service and the mesh service will be transmitted through the channel in the mTLS encryption mode, solving the connection failure problem caused by incompatible communication protocols in traditional scenarios.

[0056] If the bidirectional authentication encryption channel establishment request is initiated by the mesh service, the service mesh proxy of the mesh service selects a matching application layer protocol identifier from the application layer protocols it supports based on the non-mesh service address and application layer protocol information, generates a TLS handshake request that meets the protocol requirements of the non-mesh service, and initiates the TLS handshake request after converting the traffic to mTLS format. The non-mesh service completes the response and authentication based on its support for the protocol, and finally establishes a first bidirectional authentication encryption channel, ensuring that the mesh service's request to the non-mesh service can also be implemented through compatible communication protocols for secure encrypted communication.

[0057] Case two, establishing a second bidirectional authentication encryption channel between the first object and the second object.

[0058] wherein the first object and the second object are both non-mesh services, or the first object is a gateway and the second object is a target service.

[0059] When the first object and the second object (both of which are non-mesh services, or a gateway and a target service) initiate a bidirectional authentication encrypted channel establishment request, a second bidirectional authentication encrypted channel between the first object and the second object is established based on the internal bidirectional authentication certificate issued by the zero-trust proxy client.

[0060] Specifically, for the scenario of establishing a bidirectional authentication encrypted channel between non-mesh services: Since non-mesh services are not connected to the service mesh, there is a lack of encryption and identity authentication mechanism in traditional communication. In the technical solution of the present application, both parties have obtained an internal bidirectional authentication certificate through a zero-trust proxy client, so when initiating a request, the certificates of the other party will be exchanged and verified first, and the identity authenticity is confirmed by verifying the legality of the certificate (such as whether it is issued by an authorized agency, whether it is within the valid period), to avoid man-in-the-middle attacks. After identity verification, an encryption algorithm is negotiated based on the public key in the certificate, and a second bidirectional authentication encrypted channel is established, so that the traffic between non-mesh services is transmitted in an encrypted form, solving the risk of data leakage.

[0061] For the scenario of establishing a bidirectional authentication encrypted channel between a gateway and a target service: In view of the problem of plaintext transmission of internal traffic after the gateway offloads the certificate in the traditional architecture, the gateway and the target service (which can be a mesh service or a non-mesh service) both hold an internal bidirectional authentication certificate issued by the zero-trust proxy client. When the gateway receives an external request and needs to forward it to the target service, both parties complete bidirectional identity authentication by exchanging certificates, and establish a second bidirectional authentication encrypted channel based on the certificate, so that the internal traffic that may have been transmitted in plaintext is encrypted through the channel, ensuring the security of the entire link from the gateway to the target service.

[0062] The technical solution provided by the embodiments of the present application expands the application layer protocol support capability of the service mesh proxy in the cluster by configuring the service mesh proxy of the mesh service to support the application layer protocol used by the non-mesh service, so that it is compatible with both the internal protocol of the service mesh and the external protocol of the service mesh, thereby solving the communication protocol compatibility problem of cross-type services and further constructing a first bidirectional authentication encrypted channel between the non-mesh service and the mesh service. At the same time, a second bidirectional authentication encrypted channel is established between the two communication objects (including between non-mesh services, between a gateway and a target service), effectively eliminating the security risks of plaintext transmission of internal traffic and non-encrypted communication of non-mesh services. Through the two types of bidirectional authentication encrypted channels, the technical solution not only guarantees the protocol interworking under the hybrid service architecture, but also implements zero-trust security reinforcement for all-scenario communication, which can resist network attacks such as eavesdropping, tampering, and identity forgery, and provides a compatible and secure communication environment for all services in the cluster.

[0063] Referring to Figure 2 An embodiment flow chart of another service communication method provided for embodiments of the present application is shown. Figure 2 The flow chart shown in Figure 1 Based on the flow chart shown, an exemplary implementation of configuring a service mesh proxy of a mesh service in a cluster to support an application layer protocol used by a non-mesh service in the cluster is described. As shown in Figure 2 The flow chart shown includes the following steps: Step 201, register a service address of the non-mesh service to a service discovery mechanism of the mesh service, so that the mesh service discovers the non-mesh service.

[0064] In an embodiment, in step 201, registering the service address of the non-mesh service to the service discovery mechanism of the mesh service means: registering the service address of the non-mesh service to an out-of-mesh service declaration resource, so that the out-of-mesh service declaration resource synchronizes the address information of the non-mesh service to the mesh service, so that the mesh service discovers the non-mesh service.

[0065] Among them, the out-of-mesh service declaration resource (such as ServiceEntry in Istio) is the core mechanism to define the out-of-mesh service, which is an important supplement to the discovery mechanism of the in-mesh service (i.e. mesh service), and it ensures that the in-mesh service can accurately discover and locate the address of the out-of-mesh service (i.e. non-mesh service). The non-mesh service is not connected to the service mesh, so its service address (such as IP, port, domain name, etc.) is not visible to the mesh service and the service mesh proxy by default. Therefore, the address information of the non-mesh service is registered in advance through this mechanism.

[0066] After registration, the out-of-mesh service declaration resource synchronizes the address information of the non-mesh service to the service mesh control plane (such as Istiod), and then the control plane issues it to the service mesh proxy (such as Envoy) in the data plane. This process explicitly informs the service mesh proxy which non-mesh services need to be processed, providing a basis for subsequent protocol configuration and traffic forwarding. If the service mesh proxy does not know the existence of the non-mesh service, it cannot process its traffic even if it is configured to support the protocol.

[0067] In addition, after the discovery of the non-mesh service is completed, in order to ensure the security of the communication process, the security rules that the communication between the mesh service and the non-mesh service should follow can be further defined through a protocol conversion strategy (such as PeerAuthentication in Istio). The core of this strategy is "mandatory encryption", that is, regardless of whether the communication is initiated from the non-mesh service to the mesh service or from the mesh service to the non-mesh service, all traffic transmitted in the network must use a two-way authentication encryption mode. The purpose is to completely eliminate the phenomenon of clear text transmission and effectively prevent security threats such as data theft or tampering during transmission.

[0068] The implementation of the above protocol conversion strategy and the aforementioned "configuring the service mesh proxy of the grid service in the cluster to support the application layer protocol used by the non-grid service in the cluster" form a highly efficient synergistic effect. Specifically, the support of the application layer protocol focuses on solving the basic problem in the communication process: whether the format used for communication can be accurately identified to ensure that both parties can interact data based on a unified standard; and the protocol conversion strategy focuses on solving the more critical security problem after identifying the communication format: based on the identification, how to ensure the security of data in the transmission process to prevent data leakage or malicious attacks.

[0069] For example, even if the grid proxy already has the ability to support the application layer protocol used by the non-grid service, if the above protocol conversion strategy is not configured, the traffic may still be transmitted in plaintext form during communication, which undoubtedly brings huge security risks to the entire communication system. Once the protocol conversion strategy is configured, the grid proxy can automatically encrypt the traffic based on accurate identification of the protocol type, ensuring that both parties can communicate securely and encryptedly through compatible communication protocols.

[0070] Step 202, based on the service address registration information of the non-grid service, extending the application layer protocol identifier set supported by the service mesh proxy, so that the application layer protocol identifier used by the non-grid service is included in the application layer protocol identifier set.

[0071] In an embodiment, the application layer protocol identifier set supported by the service mesh proxy is maintained in the proxy configuration filter, and the application layer protocol identifier used by the non-grid service is configured in the application layer protocol identifier set.

[0072] Among them, the proxy configuration filter is a mechanism for modifying the control plane generated configuration supported by the service mesh, such as EnvoyFilter in Istiod. Users can customize all configurations generated by the control plane through the proxy configuration filter (such as EnvoyFilter), so as to conveniently adjust the range of application layer protocols supported by the service mesh proxy.

[0073] At the protocol identification management level, the service mesh agent identifies the application layer protocol through the application layer protocol identifier (such as h2 represents HTTP / 2, http / 1.1 represents HTTP / 1.1) in the ALPN field. In the traditional architecture, the application layer protocol identifier set maintained in the proxy configuration filter only contains the internal protocol of the service mesh (such as the Istio exclusive protocol identifier), which causes the application layer protocol identifier used by the non-mesh service (such as the standard HTTP protocol identifier) to be unable to be correctly identified. This mismatch of protocol identifiers will directly cause the protocol negotiation failure in the TLS handshake phase, which is manifested as a connection establishment timeout or a clear text transmission warning.

[0074] To this end, in step 202, the application layer protocol identifier used by the non-mesh service (such as h2, http / 1.1, etc.) is dynamically injected in the proxy configuration filter. In specific implementation, a custom protocol_options configuration is inserted into the HTTP connection manager (HttpConnectionManager) of the proxy through the typed_config field of EnvoyFilter, and the target protocol identifier (i.e., the application layer protocol identifier used by the non-mesh service) is added to the alpn_protocols list (i.e., the application layer protocol identifier set).

[0075] The extended application layer protocol identifier set forms a composite identification capability with internal and external protocols, enabling the service mesh agent to correctly parse the ALPN identifier sent by the non-mesh service in the TLS handshake phase, thereby providing a protocol layer compatible basis for subsequent mTLS encrypted channel establishment.

[0076] Step 203, hot loading the extended application layer protocol identifier set to the service mesh agent.

[0077] Hot loading refers to dynamically loading the updated proxy configuration filter (containing the extended application layer protocol identifier set) into the service mesh agent without interrupting the running of the service mesh agent, so that the newly added application layer protocol identifier takes effect. This processing method ensures that the service mesh agent completes configuration update in continuous operation, which not only ensures the immediate effect of protocol support capability, but also does not affect the normal communication of existing services.

[0078] Figure 2 The illustrated process implements the configuration of the service mesh agent of the mesh service in the cluster to support the application layer protocol used by the non-mesh service in the cluster, providing a protocol layer compatible basis for subsequent mTLS encrypted channel establishment.

[0079] In an embodiment, the technical solution provided by the embodiment of the application further includes: in the case where it is detected that the transport layer security protocol of the grid service and the non-grid service changes, updating the application layer protocol identifier set supported by the service grid agent, so that the updated application layer protocol identifier set adapts to the changed transport layer security protocol; and the service grid agent applies the updated application layer protocol identifier set through a hot loading manner.

[0080] The above embodiment provides a mechanism for the service grid agent to adaptively adjust when the transport layer security protocol of the grid service and the non-grid service changes dynamically. The core purpose is to ensure that the service grid agent is always compatible with the current transport layer security protocol, and to avoid communication interruption or security vulnerabilities caused by protocol changes.

[0081] Specifically, when it is detected that the transport layer security protocol of the grid service and the non-grid service changes, the application layer protocol identifier set maintained by the service grid agent is automatically updated, so that the updated set adapts to the changed transport layer security protocol. Here, adaptation refers to the fact that the updated application layer protocol identifier set contains specific identifiers compatible with the authentication logic of the changed transport layer security protocol, and these identifiers are used to trigger the service grid agent to perform the authentication process (such as whether two-way certificate verification is required) according to the requirements of the changed transport layer security protocol. In this way, the service grid agent can correctly identify the application layer data stream format between the non-grid service and the grid service, and cooperate with the configuration of the transport layer security protocol (such as the encryption suite, the authentication mechanism, etc.) to complete the communication, ensuring that the authentication logic is consistent with the latest transport layer security protocol requirements, and thus ensuring the security and compatibility of the communication. Subsequently, the updated set is applied to the service grid agent through a hot loading manner, ensuring that the adjustment process does not interrupt service operation. This mechanism realizes seamless adaptation in the transport layer security protocol change scenario, ensuring the continuity of communication and maintaining the security level matching the current protocol.

[0082] Further, in an embodiment, the change of the communication protocol of the grid service and the non-grid service includes: the change of the communication protocol of the grid service and the non-grid service from a one-way authentication transport layer security protocol to a two-way authentication transport layer security protocol. Accordingly, in this embodiment, updating the application layer protocol identifier set supported by the service grid agent includes: adding an application layer protocol identifier for triggering a two-way authentication process in the application layer protocol identifier set supported by the service grid agent.

[0083] Specifically, the mutual authentication transport layer security protocol (mTLS) requires both parties (mesh services and non-mesh services) to provide and verify each other's certificate, achieving strict two-way identity authentication; while the one-way authentication transport layer security protocol (one-way TLS) only requires the server to provide a certificate, and the client verifies the identity of the server, without the need for the client to provide a certificate to the server. When the communication protocol between mesh services and non-mesh services changes from mTLS to one-way TLS, it means that the identity authentication strength of the communication is reduced, and there is no longer a need for certificate interaction between both parties.

[0084] Then, in the set of application layer protocol identifiers supported by the service mesh proxy, an application layer protocol identifier for triggering a two-way authentication process is added, which is used to declare to the other party in the TLS handshake phase that "two-way certificate verification is required", for example, a protocol field identifying the mTLS specific negotiation logic. After adding the relevant identifier, the service mesh proxy will explicitly deliver the two-way authentication requirement in the handshake phase, and the non-mesh service will provide the client certificate accordingly, and the identity verification between both parties will be completed to ensure that the mTLS protocol is properly effective.

[0085] In another embodiment, the communication protocol between mesh services and non-mesh services changes from a two-way authentication transport layer security protocol to a one-way authentication transport layer security protocol. Accordingly, in this embodiment, the set of application layer protocol identifiers supported by the service mesh proxy is updated, including: in the case where the communication protocol changes from a two-way authentication transport layer security protocol to a one-way authentication transport layer security protocol, removing the application layer protocol identifier for triggering a two-way authentication process from the set of application layer protocol identifiers supported by the service mesh proxy.

[0086] After removing the application layer protocol identifier for triggering a two-way authentication process, the service mesh proxy will adapt the protocol logic of one-way TLS and only verify the server certificate to complete the TLS handshake, ensuring communication compatibility.

[0087] The above embodiments provide a service mesh proxy adaptive adjustment mechanism, which dynamically updates the set of application layer protocol identifiers when the transport layer security protocol of mesh services and non-mesh services changes dynamically, ensuring that the service mesh proxy always remains compatible with the current transport layer security protocol, effectively avoiding communication interruptions or potential security vulnerabilities caused by protocol changes.

[0088] In an embodiment, an exemplary implementation of the zero-trust agent client issuing internal two-way authentication certificates to the gateway and non-mesh services in the cluster includes: discovering, by the zero-trust agent client, the gateway and non-mesh services in the cluster through a cluster service discovery mechanism; based on the service information discovered by the zero-trust agent client, requesting the certificate authority to generate corresponding internal two-way authentication certificates, and distributing the internal two-way authentication certificates to the gateway and non-mesh services in the cluster through the zero-trust agent client. By "discovery", it means that the zero-trust agent client dynamically identifies, perceives and acquires the network endpoints (IP addresses, ports) and metadata (such as service name, label) of the gateway services and non-mesh services existing in the cluster.

[0089] The above embodiment describes the core process of the zero-trust agent client issuing internal two-way authentication certificates to the gateway and non-mesh services. Specifically, the process is divided into three steps: first, the zero-trust agent client perceives the existence and location of the gateway and non-mesh services in the cluster in real time through a cluster service discovery mechanism (such as Kubernetes Service Discovery), including service P, port, identifier and other information, to ensure that all services can be accurately identified; second, based on the discovered service information, the zero-trust agent client (or in cooperation with related components) initiates a request to the certificate authority to generate a unique internal two-way authentication certificate for each service (including the gateway) (the certificate contains service identity identifier, public key and other information); finally, the zero-trust agent client distributes the generated certificate to the corresponding gateway and non-mesh services, completing the initial deployment of the certificate.

[0090] This process solves the problem of non-mesh services and gateways lacking certificate management capabilities due to not accessing the service mesh, ensures that there is no omission in certificate distribution through service discovery, and ensures that the certificate is only given to authorized objects through targeted distribution, providing a secure credential basis for the establishment of a two-way authentication encrypted channel.

[0091] In addition, for the scenario of dynamically adding gateways / non-service meshes in the cluster, through the above embodiment, the cluster service discovery mechanism can be used to continuously monitor the cluster state changes, automatically identify the attribute information (including service identifier, port, etc.) of the newly added services, and trigger the certificate issuance process, ensuring that the certificate deployment in the dynamic environment is real-time, non-missing and limited to authorized objects, so as to ensure that the newly added services can immediately establish a secure encrypted channel.

[0092] On the basis of the above embodiment, the present application further provides the following embodiments, which are aimed at building a more perfect and reliable certificate management system to provide all-round and continuous protection for cluster communication security.

[0093] In one embodiment, a new internal two-way authentication certificate is requested from a certificate authority at a preset period, and then distributed to gateways and non-mesh services in the cluster via a zero-trust proxy client.

[0094] To avoid security risks arising from long-term certificate validity (such as the long-term misuse of a leaked certificate private key), this embodiment designs a periodic certificate update mechanism. Specifically, the certificate update process is automatically triggered according to a preset cycle (such as 7 days or 30 days, which can be adjusted according to the business security level): The zero-trust proxy client requests the certificate authority to generate new internal two-way authentication certificates for the gateway and non-mesh services based on the latest service discovery information; after generation, the new certificates are distributed to the gateway and non-mesh services through the zero-trust proxy client, completing the seamless rotation of internal two-way authentication certificates.

[0095] In one embodiment, upon detecting a leak of an internal two-way authentication certificate, a certificate revocation request is sent to the Certificate Authority (CA), and based on service information discovered by the zero-trust proxy client, a request is made to the CA to generate a new internal two-way authentication certificate. The new internal two-way authentication certificate is then distributed to the gateways and non-mesh services in the cluster via the zero-trust proxy client.

[0096] In addition to regular updates, when certificates face sudden security risks (such as private key leakage), the solutions provided in the above embodiments support emergency handling mechanisms that can quickly block risks and restore a secure state.

[0097] Specifically: When an internal two-way authentication certificate leak is detected (e.g., abnormal certificate usage records are found through log monitoring, or private key file leak alerts are issued), the system immediately sends a certificate revocation request to the certificate authority. At the same time, based on the service information currently discovered by the zero-trust proxy client, it requests the certificate authority to generate a new internal two-way authentication certificate. Finally, the new certificate is distributed to the gateway and non-mesh services through the zero-trust proxy client, ensuring that the gateway and non-mesh services quickly switch to the new internal two-way authentication certificate and avoid security attacks caused by the leakage of the old certificate.

[0098] In one embodiment, upon detecting that the validity period of the internal two-way authentication certificate has expired, a new internal two-way authentication certificate is requested from the certificate authority based on the service information discovered by the zero-trust proxy client. The new internal two-way authentication certificate is then distributed to the gateways and non-mesh services in the cluster through the zero-trust proxy client.

[0099] Certificate expiration is a common scenario in lifecycle management, and improper handling can lead to service communication interruptions. This solution uses an automatic renewal mechanism to ensure that certificates are renewed before they expire.

[0100] Specifically, the zero-trust agent client can monitor the validity period of the certificate in real time (e.g., by periodically checking the "expiration time" field in the certificate metadata); when it detects that the validity period of the certificate has expired, it requests the certificate authority to generate a new internal two-way authentication certificate based on the service discovery information. After generation, the zero-trust agent client distributes the new internal two-way authentication certificate to the gateway and non-grid services, achieving automatic renewal of the internal two-way authentication certificate and avoiding communication interruption due to certificate expiration.

[0101] Based on the above embodiments, the present application further provides the following embodiments: In an embodiment, the zero-trust agent client distributes the new internal two-way authentication certificate to the gateway and non-grid services in the cluster, including: the zero-trust agent client synchronously distributes the new internal two-way authentication certificate to each receiving object in the cluster, and listens to the certificate receiving status of each receiving object, wherein each receiving object includes the gateway and non-grid services in the cluster; in the case where it is confirmed that each receiving object has successfully received the new internal two-way authentication certificate, the zero-trust agent client sends a certificate enablement instruction to each receiving object, respectively, to enable the new internal two-way authentication certificate in each receiving object.

[0102] In the case where it is detected that any receiving object fails to receive the new internal two-way authentication certificate, the zero-trust agent client terminates the current certificate distribution process, and each receiving object maintains the original certificate state.

[0103] This embodiment provides an "atomic operation" mechanism to eliminate potential risks caused by asynchronous certificate updates and ensure that the certificate distribution process is highly uniform and consistent. Specifically, the certificate distribution is either "fully successful" (all objects simultaneously enable the new certificate) or "fully failed" (all objects maintain the old certificate), avoiding partial object updates that lead to two-way authentication incompatibility (e.g., A uses the new certificate, B uses the old certificate, leading to communication channel establishment failure).

[0104] The specific steps include: the zero-trust agent client synchronously sends the new internal two-way authentication certificate to all target receiving objects (gateway and non-grid services), and caches the receiving status of each object in real time (e.g., "received", "not received", "receiving failed"), ensuring control over the distribution progress. Only when it is confirmed that all receiving objects have successfully received the new internal two-way authentication certificate, the zero-trust agent client sends a "certificate enablement instruction" to each object, enabling all services to configure the new internal two-way authentication certificate to the active state at the same time, avoiding communication incompatibility caused by partial service updates.

[0105] If it is detected that any receiving object fails to receive the new internal mutual authentication certificate (such as network failure, service offline), the zero trust proxy client immediately terminates the current distribution process, and all receiving objects maintain the original certificate state. Exemplarily, the distribution is re-initiated after the failure is resolved, preventing communication interruption caused by inconsistent service certificates.

[0106] The above embodiments form a complete certificate life cycle management system, realize safe and efficient management of internal mutual authentication certificates, and provide support for zero trust security of service communication in the cluster.

[0107] Figure 3 An embodiment block diagram of a service communication device provided by the embodiments of the present application is shown in FIG. 1. As shown in FIG. 1, the device includes: Figure 3 A first mutual authentication encryption module 31 is configured to establish a first mutual authentication encryption channel between a non-grid service and a grid service in response to a request for establishing a mutual authentication encryption channel between the non-grid service and the grid service; and a service mesh proxy of the grid service is configured to support an application layer protocol used by the non-grid service. A second mutual authentication encryption module 32 is configured to establish a second mutual authentication encryption channel between a first object and a second object in response to a request for establishing a mutual authentication encryption channel between the first object and the second object.

[0108] In a possible implementation, the device further includes: A configuration module is configured to configure the service mesh proxy of the grid service to support an application layer protocol used by the non-grid service in the cluster. The service address of the non-grid service is registered to a service discovery mechanism of the grid service, so that the grid service discovers the non-grid service. Based on the service address registration information of the non-grid service, an application layer protocol identifier set supported by the service mesh proxy is extended, so that an application layer protocol identifier used by the non-grid service is included in the application layer protocol identifier set. The extended application layer protocol identifier set is hot loaded to the service mesh proxy.

[0109] In a possible implementation, the device further includes: A dynamic update module is configured to, in a case where it is detected that a transport layer security protocol of the grid service and the non-grid service is changed, update an application layer protocol identifier set supported by the service mesh proxy, so that an updated application layer protocol identifier set is adapted to the changed transport layer security protocol. The service mesh proxy applies the updated application layer protocol identifier set by a hot loading manner. ​

[0110] In a possible implementation, the grid service and the non-grid service change the transport layer security protocol, including: The communication protocol between the grid service and the non-grid service changes from a two-way authentication transport layer security protocol to a one-way authentication transport layer security protocol, or from a one-way authentication transport layer security protocol to a two-way authentication transport layer security protocol; The dynamic updating module updates the set of application layer protocol identifiers supported by the service mesh agent, including: In the case where the transport layer security protocol changes from a two-way authentication transport layer security protocol to a one-way authentication transport layer security protocol, the set of application layer protocol identifiers supported by the service mesh agent removes an application layer protocol identifier used to trigger a two-way authentication process; In the case where the communication protocol changes from a one-way authentication transport layer security protocol to a two-way authentication transport layer security protocol, the set of application layer protocol identifiers supported by the service mesh agent adds an application layer protocol identifier used to trigger a two-way authentication process.

[0111] In a possible implementation, the apparatus further includes: The certificate issuing module is configured to issue, through the zero trust agent client deployed in the cluster, internal two-way authentication certificates to gateways and non-grid services in the cluster, to establish a second two-way authentication encrypted channel between the first object and the second object based on the internal two-way authentication certificates.

[0112] In a possible implementation, the apparatus further includes: The certificate rotation module is configured to request, at a preset period, a certificate authority to generate new internal two-way authentication certificates, and distribute, through the zero trust agent client, the new internal two-way authentication certificates to gateways and non-grid services in the cluster.

[0113] In a possible implementation, the apparatus further includes: The certificate updating module is configured to, in the case where it is detected that the internal two-way authentication certificates are leaked, send a certificate revocation request to a certificate authority, and request the certificate authority to generate new internal two-way authentication certificates; and distribute, through the zero trust agent client, the new internal two-way authentication certificates to gateways and non-grid services in the cluster.

[0114] In a possible implementation, the apparatus further includes: The certificate updating module is configured to, in the case where it is detected that the internal two-way authentication certificates are expired, request a certificate authority to generate new internal two-way authentication certificates, and distribute, through the zero trust agent client, the new internal two-way authentication certificates to gateways and non-grid services in the cluster.

[0115] In a possible implementation, the certificate updating module distributes the new internal mutual authentication certificate to the gateways and non-mesh services in the cluster through the zero-trust proxy client, including: The zero-trust proxy client synchronously distributes the new internal mutual authentication certificate to each receiving object in the cluster, and monitors the certificate receiving state of each receiving object; When it is confirmed that each receiving object successfully receives the new internal mutual authentication certificate, the zero-trust proxy client sends a certificate enabling instruction to each receiving object, so that each receiving object configures the new internal mutual authentication certificate to an effective state.

[0116] In a possible implementation, the certificate updating module is further configured to: When it is detected that any receiving object fails to receive the new internal mutual authentication certificate, the zero-trust proxy client terminates the current certificate distribution process, and each receiving object maintains the original certificate state.

[0117] In a possible implementation, the apparatus further includes: a certificate issuing module configured to issue, through a zero-trust proxy client deployed in a cluster, an internal mutual authentication certificate to gateways and non-mesh services in the cluster; The zero-trust proxy client and the gateways and the non-mesh services establish a local secure communication channel between each other, and the zero-trust proxy client distributes the internal mutual authentication certificate to the gateways and the non-mesh services in the cluster through the local secure communication channel.

[0118] As shown in Figure 4 The electronic device provided by the embodiment of the present application includes a processor 111, a communication interface 112, a memory 113, and a communication bus 114, wherein the processor 111, the communication interface 112, and the memory 113 complete mutual communication through the communication bus 114, The memory 113 is configured to store a computer program. In an embodiment of the present application, the processor 111 is configured to execute the program stored in the memory 113, and implement the service communication method provided by any one of the preceding method embodiments, including: In response to a request for initiating a mutual authentication encryption channel between a non-mesh service and a mesh service, a first mutual authentication encryption channel between the non-mesh service and the mesh service is established; wherein a service mesh proxy of the mesh service is configured to support an application layer protocol used by the non-mesh service in the cluster. In response to initiating a two-way authentication encrypted channel establishment request between the first object and the second object, a second two-way authentication encrypted channel between the first object and the second object is established.

[0119] The embodiment of the present application further provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the steps of the service communication method provided by any one of the preceding method embodiments.

[0120] The apparatus embodiments described above are merely illustrative, wherein the units described as separate components can or can not be physically separate, and the components displayed as units can or can not be physical units, i.e., can be located in one place, or can be distributed on a plurality of network units. Part or all of the modules can be selected according to actual needs to achieve the purpose of the embodiment scheme.

[0121] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a general hardware platform, and of course can also be implemented by hardware. Based on such understanding, the above technical solutions can be embodied in the form of a software product, which can be stored in a computer readable storage medium, such as a ROM / RAM, a magnetic disk, an optical disk, etc., and includes a plurality of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute the methods described in each embodiment or some parts of the embodiments.

[0122] It should be understood that the terms used herein are for the purpose of describing particular example embodiments only and are not intended to be limiting. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms "comprises", "comprising", "includes", "including" and "has" are inclusive and therefore specify the presence of stated features, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order in which they are described, unless specifically indicated as such. It is also to be understood that additional or alternative steps can be employed.

[0123] The foregoing detailed description of the application has been presented for purposes of illustration and description. Various modifications and changes can be made to these embodiments without departing from the spirit and scope of the application. It is intended that the scope of the application should not be limited by the particular representative embodiments described above.

Claims

1. A service communication method, characterized in that, The method includes: In response to a request to establish a two-way authentication and encryption channel between a non-grid service and a grid service, a first two-way authentication and encryption channel is established between the non-grid service and the grid service; wherein, the service grid proxy of the grid service is configured to support the application layer protocol used by the non-grid service. In response to a request to establish a two-way authentication encrypted channel between the first object and the second object, a second two-way authentication encrypted channel is established between the first object and the second object.

2. The method according to claim 1, characterized in that, Configure the service mesh proxy to support the application layer protocols used by the non-mesh services in the following way: Register the service address of the non-grid service with the service discovery mechanism of the grid service, so that the grid service can discover the non-grid service; Based on the service address registration information of the non-mesh service, the set of application layer protocol identifiers supported by the service mesh proxy is expanded so that the application layer protocol identifiers used by the non-mesh service are included in the set of application layer protocol identifiers. The expanded set of application layer protocol identifiers is hot-loaded into the service mesh proxy.

3. The method according to claim 1, characterized in that, The method further includes: If a change in the transport layer security protocol of the grid service and the non-grid service is detected, the set of application layer protocol identifiers supported by the service grid agent is updated so that the updated set of application layer protocol identifiers is compatible with the changed transport layer security protocol. The service mesh proxy applies the updated set of application layer protocol identifiers via hot reloading.

4. The method according to claim 3, characterized in that, The transport layer security protocols for the grid service and non-grid service have been changed, including: The communication protocol between grid services and non-grid services is changed from a two-way authentication transport layer security protocol to a one-way authentication transport layer security protocol, or from a one-way authentication transport layer security protocol to a two-way authentication transport layer security protocol. The update of the set of application layer protocol identifiers supported by the service mesh proxy includes: When the transport layer security protocol is changed from a two-way authentication transport layer security protocol to a one-way authentication transport layer security protocol, remove the application layer protocol identifier used to trigger the two-way authentication process from the application layer protocol identifier set supported by the service mesh proxy. When the communication protocol is changed from a one-way authentication transport layer security protocol to a two-way authentication transport layer security protocol, an application layer protocol identifier for triggering the two-way authentication process is added to the set of application layer protocol identifiers supported by the service mesh agent.

5. The method according to claim 1, characterized in that, The method further includes: The zero-trust proxy client deployed in the cluster issues internal two-way authentication certificates to the gateway and non-mesh services in the cluster, so as to establish a second two-way authentication encrypted channel between the first object and the second object based on the internal two-way authentication certificates.

6. The method according to claim 5, characterized in that, The method further includes: The system requests the generation of a new internal two-way authentication certificate from the certificate authority according to a preset cycle, and distributes the new internal two-way authentication certificate to the gateway and non-mesh service in the cluster through the zero-trust proxy client.

7. The method according to claim 5, characterized in that, The method further includes: Upon detecting the leakage of the internal two-way authentication certificate, a certificate revocation request is sent to the certificate authority, and a request is made to the certificate authority to generate a new internal two-way authentication certificate; The new internal two-way authentication certificate is distributed to the gateway and non-mesh services in the cluster via the zero-trust proxy client.

8. The method according to claim 5, characterized in that, The method further includes: If the validity period of the internal two-way authentication certificate is detected to have expired, a new internal two-way authentication certificate is requested from the certificate authority, and the new internal two-way authentication certificate is distributed to the gateway and non-mesh service in the cluster through the zero-trust proxy client.

9. The method according to any one of claims 6-8, characterized in that, The step of distributing the new internal two-way authentication certificate to the gateway and non-mesh services in the cluster through the zero-trust proxy client includes: The zero-trust proxy client synchronously distributes the new internal two-way authentication certificate to each receiving object in the cluster and monitors the certificate receiving status of each receiving object. Upon confirming that all recipients have successfully received the new internal two-way authentication certificate, the zero-trust proxy client sends a certificate activation instruction to each recipient, so that each recipient configures the new internal two-way authentication certificate to be active.

10. The method according to claim 9, characterized in that, The method further includes: If any of the receiving objects fails to receive the new internal two-way authentication certificate, the zero-trust proxy client terminates the certificate distribution process, and each receiving object maintains its original certificate status.

11. The method according to claim 1, characterized in that, The method further includes: Internal two-way authentication certificates are issued to the gateways and non-mesh services in the cluster through a zero-trust proxy client deployed in the cluster. The zero-trust proxy client establishes local secure communication channels with the gateway and the non-mesh service, respectively, and distributes internal two-way authentication certificates to the gateway and non-mesh service in the cluster through the local secure communication channels.

12. A service communication device, characterized in that, The device includes: A two-way authentication encryption module is used to respond to a request to establish a two-way authentication encryption channel between a non-grid service and a grid service, and to establish a first two-way authentication encryption channel between the non-grid service and the grid service; wherein, the service grid proxy of the grid service is configured to support the application layer protocol used by the non-grid service; In response to a request to establish a two-way authentication encrypted channel between the first object and the second object, a second two-way authentication encrypted channel is established between the first object and the second object.

13. An electronic device, characterized in that, include: A processor and a memory, the processor being configured to execute a service communication program stored in the memory to implement the service communication method according to any one of claims 1-11.

Images