Micro-service management method and device

Abstract

The invention discloses a micro-service management method and device, and relates to the field of cloud computing. The method is applied to a server side of the distributed computing system, the server side is used for managing at least one host, the server side deploys a first micro-service on a first host, and the first host is any host in the at least one host. The method comprises the following steps: sending a first token to a first host, wherein the first token is generated by encrypting identification information of the first host, identification information of a first micro-service and an interface account of a verification interface matched with the first micro-service; receiving a first request taking a second token as a certificate, wherein the second token is generated by encrypting the first token; under the condition that the first request taking the second token as the voucher passes verification, calling the verification interface to generate a third token according to the interface account analyzed from the second token; and sending a third token to the first host, wherein the third token is used for the first micro-service to access micro-services except the first micro-service. The security of micro-service authentication can be improved.

Description

Technical Field

[0001] This application relates to the field of cloud computing, and in particular, to a method and apparatus for managing microservices. Background Art

[0002] A microservice (or microservice architecture) is a cloud-native architecture approach that includes numerous small, loosely coupled, and independently deployable components or services within a single application. These microservices typically have their own technology stacks, including databases and data management models. Communication between multiple microservices can be achieved through representational state transfer (REST) application programming interfaces (APIs), event streams, and message broker combinations. The characteristics of microservices are that the code is easier to update, new features or functions can be directly added without updating the entire application. Moreover, different technology stacks and programming languages can be used for different microservices. In other words, different microservices can be scaled independently, thereby reducing the waste and costs associated with scaling the entire application. Based on the above characteristics, microservices are widely used in cloud computing scenarios.

[0003] When multiple microservices access each other, the authentication method of microservices is too simple, and the security needs to be improved urgently. Summary of the Invention

[0004] This application provides a method and apparatus for managing microservices, which can improve the security of microservice authentication.

[0005] To achieve the above object, this application adopts the following technical solutions:

[0006] In a first aspect, a method for managing microservices is provided. The method is applied to a server of a distributed computing system. The server is used to manage at least one host, and a first microservice is deployed on a first host, where the first host is any one of the at least one host. The execution subject of the method can be the server, or a component or apparatus (such as a processor, a chip, or a chip system, etc.) applied to the server, or a logic module or software that can implement all or part of the server functions. The method includes: sending a first token to the first host, where the first token is generated by encrypting the identification information of the first host, the identification information of the first microservice, and the interface account of the verification interface matching the first microservice; receiving a first request with a second token as a credential, where the second token is generated by encrypting the first token; in the case where the first request with the second token as a credential passes the verification, calling the verification interface to generate a third token according to the interface account parsed from the second token; and sending the third token to the first host, where the third token is used for the first microservice to access microservices other than the first microservice.

[0007] In a first aspect, a first token generated based on the identification information of the first host, the identification information of the first microservice, and the corresponding interface account, and a second token generated based on the host certificate are set between the server and the first host to determine whether to generate a third token for the first microservice of the first host to access microservices other than the first microservice, ensuring that the third token is issued to the verified first host and enhancing the security of microservice management. Further, the identity of the first microservice is authenticated by encrypting the interface account corresponding to the microservice with the third token, which will not cause the account password of the first microservice to be leaked. There is no need to place the plaintext account password of the first microservice on the host, reducing the risk of account password leakage. Moreover, the server pre-sets the mapping relationship between each microservice and the authentication management service account, avoiding the risk of a large explosion radius caused by password leakage when multiple hosts use the same password for the same microservice.

[0008] Combined with the first aspect, in a possible implementation, before sending the third token to the first host, the method further includes: obtaining a microservice certificate corresponding to the first microservice according to the first request; sending the microservice certificate to the first host; receiving a second request with a fourth token as a credential, where the fourth token includes the microservice certificate and a first signature, and the first signature is a signature obtained by encrypting the expiration time of the microservice certificate with the first private key generated by the first microservice and the microservice certificate; sending the third token to the first host, including: sending the third token to the first host when the second request is verified successfully.

[0009] In this implementation, based on the double verification of the first token and the second token, a fourth token based on the microservice certificate is introduced as a verification basis to further determine whether to send a third token for the first microservice of the first host to access microservices other than the first microservice, ensuring that the third token can be issued to the verified first host and further enhancing the security of microservice management.

[0010] Combined with the first aspect, in a possible implementation, the server caches a second public key issued by the issuing authority of the microservice certificate and a first public key generated by the first microservice. The successful verification of the second request includes: being able to successfully decode the microservice certificate using the second public key, being able to successfully decode the first signature using the microservice certificate and the first public key, and the expiration time being later than the current time.

[0011] Combined with the first aspect, in a possible implementation, the second token includes: a second signature obtained by encrypting the first token and the host certificate of the first host applied when encrypting the first token.

[0012] In combination with the first aspect, in a possible implementation, the server caches a third public key for signing the host certificate of the first host and a fourth public key for signing the first token. The passing of the first request verification includes: successfully decoding the host certificate of the first host using the third public key, successfully decoding the second signature using the host certificate of the first host, successfully decoding the first token using the fourth public key, and the first information matching the second information; wherein, the first information is the identification information of the first host, the identification information of the first microservice, and the interface account used to generate the first token, and the second information is the identification information of the host requested by the first request, the identification information of the microservice, and the interface account.

[0013] In the second aspect, a method for managing microservices is provided. The method is applied to the first host of a distributed computing system. The server in the distributed computing system is used to manage at least one host, and the first host is any one of the at least one host. The server deploys a first microservice on the first host. The execution subject of this method can be the first host, or a component or device applied to the first host (such as a processor, a chip, or a chip system, etc.), or a logical module or software that can implement all or part of the functions of the first host. The method includes: receiving a first token, which is generated based on the identification information of the first host, the identification information of the first microservice, and the interface account of the verification interface matching the first microservice; calling a trusted platform node in the first host to encrypt the first token to generate a second token; sending a first request with the second token as a credential to the server; the first request is used to generate a third token according to the interface account parsed from the second token; receiving the third token, which is used for the first microservice to access microservices other than the first microservice.

[0014] In the second aspect, a first token generated based on the identification information of the first host, the identification information of the first microservice, and the corresponding interface account and a second token generated based on the host certificate are set between the server and the first host to determine whether to generate a third token for the first microservice of the first host to access microservices other than the first microservice, ensuring that the third token is issued to the first host that passes the verification and enhancing the security of microservice management. Further, the identity of the first microservice is authenticated by encrypting the interface account corresponding to the microservice with the third token, which will not cause the account password of the first microservice to be leaked. There is no need to place the plaintext account password of the first microservice on the host, reducing the risk of account password leakage. Moreover, the server pre-sets the mapping relationship between each microservice and the authentication management service account, avoiding the risk of a large explosion radius caused by password leakage when multiple hosts use the same password for the same microservice.

[0015] In combination with the second aspect, in a possible implementation, before receiving the third token, the method further includes: receiving a microservice certificate; encrypting the expiration time of the microservice certificate with a first secret key and the microservice certificate generated by the first microservice to obtain a first signature; synthesizing the first signature and the microservice certificate to obtain a fourth token; and sending a second request using the fourth token as a credential, where the second request is used to request the third token.

[0016] In this implementation, on the basis of the dual verification of the first token and the second token, a fourth token based on the microservice certificate is introduced to further determine whether to send a third token for the first microservice of the first host to access microservices other than the first microservice, ensuring that the third token can be issued to the verified first host and further enhancing the security of microservice management.

[0017] In combination with the second aspect, in a possible implementation, calling a trusted platform node in the first host to encrypt the first token to generate a second token includes: calling the trusted platform node to encrypt the first token according to the host certificate of the first host to obtain a second signature; and synthesizing the host certificate of the first host and the second signature to obtain the second token.

[0018] In a third aspect, a management device for microservices is provided. The device is applied to the server side of a distributed computing system. The server side is used to manage at least one host, and the first microservice is deployed on the first host, where the first host is any one of the at least one host. The communication device can be the server side or a chip or system-on-chip in the server side. The communication device can implement the functions executed by the server side in the first aspect or the possible designs of the first aspect. The functions can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. For example, the communication device includes: a sending module for sending a first token to the first host, where the first token is generated by encrypting the identification information of the first host, the identification information of the first microservice, and the interface account of the verification interface matching the first microservice; a receiving module for receiving a first request using the second token as a credential, where the second token is generated by encrypting the first token; a generating module for, when the first request using the second token as a credential is verified, calling the verification interface to generate a third token according to the interface account parsed from the second token; and the sending module is further used to send the third token to the first host, where the third token is used for the first microservice to access microservices other than the first microservice.

[0019] In combination with the third aspect, in a possible implementation, the device further includes an obtaining module, configured to obtain a microservice certificate corresponding to the first microservice according to a first request before sending a third token to the first host; a sending module, configured to send the microservice certificate to the first host; a receiving module, configured to receive a second request with a fourth token as a credential, where the fourth token includes the microservice certificate and a first signature, and the first signature is a signature obtained by encrypting the expiration time of the microservice certificate with a first private key generated by the first microservice and the microservice certificate; the sending module is specifically configured to: send the third token to the first host when the second request is verified successfully.

[0020] In combination with the third aspect, in a possible implementation, the server caches a second public key issued by the issuing authority of the microservice certificate and a first public key generated by the first microservice. The successful verification of the second request includes: being able to successfully decode the microservice certificate using the second public key, being able to successfully decode the first signature using the microservice certificate and the first public key, and the expiration time being later than the current time.

[0021] In combination with the third aspect, in a possible implementation, the second token includes: a second signature obtained by encrypting the first token and the host certificate of the first host applied when encrypting the first token.

[0022] In combination with the third aspect, in a possible implementation, the server caches a third public key for issuing the host certificate of the first host and a fourth public key for issuing the first token. The successful verification of the first request includes: being able to successfully decode the host certificate of the first host using the third public key, being able to successfully decode the second signature using the host certificate of the first host, being able to successfully decode the first token using the fourth public key, and the first information matching the second information; where the first information is the identification information of the first host, the identification information of the first microservice, and the interface account number used to generate the first token, and the second information is the identification information of the host requested by the first request, the identification information of the microservice, and the interface account number.

[0023] Fourth aspect, there is provided a management device for microservices. The device is applied to a first host of a distributed computing system. The server in the distributed computing system is used to manage at least one host, and the first host is any one of the at least one host. The server deploys a first microservice on the first host. The communication device may be the first host or a chip or system-on-chip in the first host. The communication device can implement the functions performed by the first host in the second aspect or any possible design of the second aspect. The functions can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. For example, the communication device includes: a receiving module, configured to receive a first token, the first token being generated based on the identification information of the first host, the identification information of the first microservice, and the interface account of the verification interface matching the first microservice; an encryption module, configured to call a trusted platform node in the first host to encrypt the first token to generate a second token; a sending module, configured to send a first request using the second token as a credential to the server; the first request is used to generate a third token according to the interface account parsed from the second token; the receiving module is further configured to receive the third token, and the third token is used for the first microservice to access microservices other than the first microservice.

[0024] In combination with the fourth aspect, in a possible implementation, the device further includes a synthesizing module; the receiving module is further configured to receive a microservice certificate before receiving the third token; the encryption module is further configured to encrypt the expiration time of the microservice certificate with a first secret key generated by the first microservice and the microservice certificate to obtain a first signature; the synthesizing module is configured to synthesize the first signature and the microservice certificate to obtain a fourth token; the sending module is configured to send a second request using the fourth token as a credential, and the second request is used to request the third token.

[0025] In combination with the fourth aspect, in a possible implementation, the generating module is specifically configured to: call the trusted platform node to encrypt the first token according to the host certificate of the first host to obtain a second signature; synthesize the host certificate of the first host and the second signature to obtain the second token.

[0026] Fifth aspect, the present application provides a cluster of computing devices. The cluster of computing devices includes at least one computing device. Each device in the at least one computing device includes at least one processor and at least one memory. The at least one memory stores computer-readable instructions; the at least one processor executes the computer-readable instructions so that the cluster of computing devices executes the methods described in the first aspect, any possible implementation manner of the first aspect, the second aspect, or any possible implementation manner of the second aspect.

[0027] Sixth aspect, the present application provides a computer program product including instructions, which, when executed by a cluster of computing devices, cause the cluster of computing devices to execute the methods described in the first aspect, any possible implementation manner of the first aspect, the second aspect, or any possible implementation manner of the second aspect.

[0028] Seventh aspect, the present application provides a computer-readable storage medium storing computer program instructions, which, when executed by a cluster of computing devices, cause the cluster of computing devices to execute the methods described in the first aspect, any possible implementation manner of the first aspect, the second aspect, or any possible implementation manner of the second aspect.

[0029] Among them, the beneficial effects described in the third aspect to the seventh aspect of the present application can be analyzed with reference to the beneficial effects of the first aspect or the second aspect, and will not be elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 It is a schematic diagram of a microservice access process provided by an embodiment of the present application;

[0031] Figure 2 It is a schematic diagram of the structure of a distributed system provided by an embodiment of the present application;

[0032] Figure 3 It is a schematic diagram of the process of a microservice management method provided by an embodiment of the present application;

[0033] Figure 4 It is a schematic diagram of the process of another microservice management method provided by an embodiment of the present application;

[0034] Figure 5 It is a schematic diagram of the process of another microservice management method provided by an embodiment of the present application;

[0035] Figure 6 It is a schematic diagram of the structure of a data processing device provided by an embodiment of the present application;

[0036] Figure 7 It is a schematic diagram of the structure of another data processing device provided by an embodiment of the present application;

[0037] Figure 8 It is a schematic diagram of the structure of a computing device provided by an embodiment of the present application;

[0038] Figure 9 It is a schematic diagram of the structure of a cluster of computing devices provided by an embodiment of the present application;

[0039] Figure 10 It is a schematic diagram of the structure of another cluster of computing devices provided by an embodiment of the present application. Specific Embodiments

[0040] The network architecture and service scenarios described in the embodiments of this application are to more clearly illustrate the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. Those of ordinary skill in the art will know that with the evolution of the network architecture and the emergence of new service scenarios, the technical solutions provided by the embodiments of this application are equally applicable to similar technical problems.

[0041] It should be noted that the terms "first" and "second" in the description, claims, and drawings of this application are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but optionally further includes steps or units not listed, or optionally further includes other steps or units inherent to these processes, methods, products, or devices.

[0042] It should be understood that in the embodiments of this application, "at least one (item)" means one or more, "multiple" means two or more, "at least two (items)" means two or three or more, and "and / or" is used to describe the association relationship of associated objects, indicating that three relationships can exist. For example, "A and / or B" can mean: only A exists, only B exists, and both A and B exist at the same time. Among them, A and B can be singular or plural. The character " / " generally means that the associated objects before and after are in an "or" relationship. "At least one (item) of the following" or its similar expressions refer to any combination of these items, including any combination of single items (items) or plural items (items). For example, at least one (item) of a, b, or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple. It should be understood that in the embodiments of this application, "B corresponding to A" means that B is associated with A. For example, B can be determined according to A. It should also be understood that determining B according to A does not mean determining B only according to A, but B can also be determined according to A and / or other information. In addition, the "connection" mentioned in the embodiments of this application refers to various connection methods such as direct connection or indirect connection to achieve communication between devices, and this application does not make any limitations on this.

[0043] It should be noted that in the description, claims and drawings of this application, terms such as "first" and "second" are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally also include unlisted steps or units, or may optionally also include other steps or units inherent to these processes, methods, products or devices.

[0044] Before introducing the embodiments of this application, some terms related to the embodiments of this application are explained.

[0045] (1) Host: In a distributed computing environment (also known as a distributed computing system), it refers to a node used to execute computing tasks.

[0046] (2) Micro Service: It refers to a collection of programs for completing a certain task or process.

[0047] (3) Public-Private Key Pair: It is a key pair obtained through an encryption algorithm. The key publicly disclosed by the holder of the public-private key pair is called the public key, and the key not publicly disclosed is called the private key. The private key can encrypt data, and the public key can decrypt data.

[0048] (4) Certificate Signing Request (CSR): It is information in a specific format generated by the holder of the public-private key pair using the private key and is used to apply for a certificate.

[0049] (5) Digital Certificate (CRT): It is a digital file generated by a Certificate Authority (CA) based on the CSR. The authenticity of the certificate can be verified using the public key signed by the CA. Since generating a specific CSR requires using a specific public-private key pair, holding a certificate can be considered that the corresponding public-private key pair is recognized by the CA.

[0050] (6) Cryptographic Message Syntax (CMS): It encodes a specific piece of information using the private key and the CRT, and the result of the encoding is called a signature (also known as a digital signature). The authenticity of the signature can be verified using the CRT.

[0051] (7) Token: In computer science, it is a credential used to represent authentication, authorization, and access control, usually a randomly generated string. It can be generated using various methods or custom methods.

[0052] (8) Keystone token: A token issued by the OpenStack authentication and authorization component Keystone, used for authentication and permission control between components within the OpenStack system.

[0053] (9) JWT token (Json Web token): A token generated using a private key according to the RFC 7519 standard, and its authenticity can be verified using a public key. JWT tokens are suitable for one-to-one scenarios. In other words, one public key corresponds to one private key.

[0054] (10) Cert token: A type of token designed in this application, which consists of two parts: CRT and digital signature. When verifying a Cert token, it needs to be verified in two steps. First, use the CA public key to verify the legality of the CRT, and then use the CRT to verify the legality of the digital signature.

[0055] Cert tokens are suitable for one-to-many scenarios. In other words, one public key can decode multiple private keys. It realizes the correct verification of information signed by multiple private keys using one CA public key.

[0056] (11) Trusted Platform Module (TPM): A hardware security chip on the host that can sign data using a public-private key pair to prove that the data comes from a specific host. The private key of the TPM is generally not exportable to avoid data forgery.

[0057] (12) Virtual Trusted Platform Module (VTPM): A TPM implemented through software simulation using virtual technology. It can also prove that the data comes from a specific host. The private key of the VTPM is encrypted to avoid private key export and data forgery.

[0058] When multiple microservices access each other, as Figure 1 shown, the access is achieved through the following steps:

[0059] Step 1, the microservice obtains the plaintext "username and password" from the host's deployment system and saves it as the host account locally on the host;

[0060] Step 2, the microservice applies for a token from Keystone with the plaintext "username and password" via the network;

[0061] Step 3, Keystone verifies the "username and password". After successful verification, it generates a short-term Keystone token and provides it to the microservice;

[0062] Step 4, the microservice uses a Keystone token to access other microservices.

[0063] It can be seen that when the microservice applies for a Keystone token, it still needs to transmit the plaintext password through the network, which has a certain degree of insecurity. Moreover, the host account is stored locally on the host, and there is a risk of password leakage. In addition, for a distributed system, when the same microservice is deployed on multiple hosts, it is very likely that the same password will be configured. After the password is leaked in this way, it will affect multiple hosts, and the blast radius is relatively large.

[0064] To solve the above technical problems, the embodiments of the present application provide a management method for microservices, which uses a digital certificate-based system to bind the microservice to the corresponding token account. That is, one microservice corresponds to a set of certificates and a token account. In other words, the certificates and token accounts used by different microservices are different. At the same time, a token is applied for with the certificate, and the token account is encrypted based on the token. In this way, the encrypted token account replaces the plaintext microservice account password method, avoiding the risk of a large blast radius caused by password leakage when multiple hosts use the same password for the same microservice. Moreover, by transmitting the account in the form of a token, there is no need to place the plaintext "username and password" on the host, reducing the risk of password leakage.

[0065] Next, the system and method provided by the embodiments of the present application will be described with reference to the accompanying drawings of the specification.

[0066] The communication method provided by the embodiments of the present application can be applied to a distributed system, which can also be referred to as a distributed computing system, a distributed cluster, etc. It is a group of interconnected computers or servers that work together to perform a common task. The computers or servers in a distributed system are usually located in different physical locations and are interconnected through a network. Distributed systems are usually used to provide high availability, scalability, and fault tolerance for applications and services. In a distributed system, each computer or server can be called a node, and multiple nodes constitute the distributed system.

[0067] Exemplarily, the distributed system can be as Figure 2 shown, Figure 2 is a schematic structural diagram of a data access system provided by the present application. The data access system includes a distributed system 100, and the distributed system 100 includes: a network device 130 and multiple server nodes (which can be simply referred to as servers): node 111, node 112, and node 113. A server node is used to process part of the data in the distributed system 100, and the server node communicates with the host (client) through a network or a hardware communication channel. It should be understood that, Figure 2This is only an example provided for this embodiment. The distributed system 100 may include more or fewer server nodes, which is not limited in this application.

[0068] The distributed system 100 can support multiple hosts (also known as clients) to process and access files, data, etc. in the server nodes. The multiple hosts may include Figure 2 the hosts 1, 2, and 3 shown. It should be noted that the distributed system 100 can also support more or fewer hosts for data processing and access. Among them, a host, or client, user end, etc., can be a computer running an application program. The computer running the application program can be a physical machine or a virtual machine. For example, if the computer running the application program is a physical computing device, the physical computing device can be a host or a terminal.

[0069] In addition to the distributed cluster introduced above, the distributed cluster in the embodiments of this application can also be a cloud server. For example, a public cloud server, a private cloud server, a hybrid cloud server, etc. Although a cloud server is not a traditional distributed cluster (because a cloud server is not a group of interconnected physical servers), it can be considered a virtual distributed cluster. This is because a cloud server is usually hosted on a hypervisor, which is a virtualization platform that allows multiple virtual machines to run on a single physical server. Each virtual machine is equivalent to a node, and multiple nodes form a distributed cluster.

[0070] In a distributed system, the server is used to manage at least one host. The server pre-sets the mapping relationship between each microservice and the authentication management service account through the control system. In other words, one microservice corresponds to one authentication management service account (also known as the interface account of the verification interface). The server deploys at least one microservice on the first host, where the first microservice is any one of the at least one microservices, and the first host is any one of the at least one hosts.

[0071] Exemplarily, in the embodiments of this application, the server deploys a control system (which can also be called a deployment system), an authentication management service, and a certificate issuance service.

[0072] Among them, the control system is used to manage the various functional services in the server. For example, the authentication management service, the certificate issuance service, etc., and deploy microservices for the host, and record the corresponding relationship between the microservice and the authentication management service account.

[0073] The authentication management service is responsible for functions such as identity verification, service rules, and service tokens. In other words, the authentication management service can provide a verification interface and generate corresponding authentication management service tokens.

[0074] The certificate issuance service is used to obtain digital certificates from a certificate authority and issue them to hosts, microservices, etc.

[0075] It should be noted that the certificate authority can be a party other than the operator of the server side, and the certificate issuance service obtains various digital certificates from other parties. The certificate authority can also be the operator of the server side, and the operator of the server side sets functions for issuing various digital certificates in the certificate issuance service, without limitation.

[0076] In addition, in a distributed system, a trusted platform node is deployed on the host, and the trusted platform node is used to sign data, thereby proving that the data comes from a specific host. In other words, the trusted platform node bears the function of proving that the data comes from this host, and the certificate issuance service needs to identify which host the message comes from according to the information signed by the trusted platform node to avoid forgery. Among them, the trusted platform node can be a TPM or a VTPM.

[0077] In one example, the control system of the server side is deployed based on the Openstack framework. Under this framework, the authentication management service is keystone (openstack identity service), and keystone (openstack identity service) is responsible for authentication, service rules, and service tokens in the Openstack framework. It implements the Identity API of Openstack. The certificate issuance service can be a newly created extended service for obtaining digital certificates from a certificate authority.

[0078] In the embodiment of the present application, the server side introduces a certificate issuance service to issue an independent certificate for each host (and each microservice). The control system ensures that the entire issuance process is trustworthy and cannot be forged. The trusted platform node ensures that the private keys of each host cannot be exported. The control system pre-sets the mapping relationship between each microservice and the authentication management service account, and the mapping relationship between a certain microservice and the corresponding authentication management service account is carried by the microservice certificate. When the certificate authority generates a microservice certificate, it first generates a key pair, including a second public key and a second private key, and then encrypts the host name of the first host, the service name of the first microservice, and the interface account with the second private key to obtain the microservice certificate of the first microservice. And the second public key is provided to the server side for caching.

[0079] After obtaining the independent microservice certificate, the microservice exchanges the authentication management service token with the authentication management service through the Cert token signed by itself, so that there is no need to exchange the authentication management service token based on the "username + password" (collectively referred to as the account) of the microservice, reducing the risk of microservice account leakage and improving the security of microservice management.

[0080] The control system of the server can also control the initialization of the trusted platform node. The purpose of initializing the trusted platform node is to establish an association between the trusted platform node and the certificate issuance service, so that the information signed by the CMS of the trusted platform node can be correctly parsed by the certificate issuance service.

[0081] Exemplarily, taking the trusted platform node as TPM as an example for introduction, the trusted platform node can be initialized through the following process:

[0082] First, each host's TPM generates a set of public and private key pairs respectively, including the third private key and the third public key. The control system extracts the third public key from each host's TPM for caching respectively, and obtains the csr generated by the TMP based on the third private key. Then, the control system calls the certificate issuance service to sign the csr to generate the host certificate. And the corresponding host certificate is imported into the TPM on each host respectively. Finally, when the microservice on the host needs to obtain host authentication, it obtains the information signed by the host certificate from the TPM.

[0083] In another example, if the trusted platform node is VTPM, the trusted platform node can be initialized through the following process:

[0084] First, the certificate issuance service issues a time-limited temporary credential to all hosts. Then, the vtpm process of each host generates a public and private key pair of the host locally, including the third private key and the third public key, and encrypts and saves the private key to avoid leakage of the private key. At the same time, the third public key is provided to the server for caching. After that, the vtpm on the host generates the host CSR with the third private key, and applies to the certificate issuance service for and obtains the host certificate within the time limit with the temporary credential. Finally, when the microservice on the host needs to obtain host authentication, it sends a request to the vtpm through cross-process communication. The vtpm signs the information with the held private key and the host certificate and returns it to the microservice.

[0085] Based on the distributed system introduced above, the embodiment of the present application provides a management method for microservices, which uses a system based on digital certificates to bind microservices to corresponding accounts. That is, one microservice corresponds to a set of certificates and an account, avoiding the risk of a large blast radius caused by password leakage when multiple hosts use the same password for the same microservice. And, the account is transmitted in the form of a token, without placing the plaintext "username and password" on the host, reducing the risk of password leakage. The management method for microservices provided by the embodiment of the present application will be described below.

[0086] In the embodiments of the present application, the device for implementing the functions of the server may be the server or a device capable of supporting the server to implement such functions, such as a chip system. This device may be installed in the server or used in matching with the server. Similarly, the device for implementing the functions of the host may be the host or a device capable of supporting the host to implement such functions, such as a chip system. This device may be installed in the host or used in matching with the host. Hereinafter, taking the device for implementing the functions of the server as the server and the device for implementing the functions of the host as the host as an example, the method provided by the embodiments of the present application will be described.

[0087] Figure 3 FIG. shows a schematic flow chart of the method for managing microservices provided by the embodiments of the present application. As Figure 3 shown, the method may include the following steps:

[0088] S310, the server sends a first token to the first host. Correspondingly, the first host receives the first token from the server.

[0089] Among them, as Figure 1 shown in the description of the distributed system, the server in the distributed system is used to manage at least one host. The server pre-sets the mapping relationship between each microservice and the authentication management service account through the control system. In other words, one microservice corresponds to one authentication management service account (i.e., the "token account" mentioned above), and the authentication management service account can also be called the interface account of the verification interface. Exemplarily, the verification interface may be the authentication and authorization component keystone in Openstack.

[0090] Optionally, different microservices correspond to different authentication management service accounts.

[0091] The server deploys at least one microservice on the first host, where the first microservice is any one of the at least one microservices, and the first host is any one of the at least one hosts. The server may generate a first token based on the identification information of the first host, the identification information of the first microservice, and the authentication management service account corresponding to the first microservice. And when deploying the first microservice on the first host, send the first token to the first host. The type of the first token can be set flexibly. Exemplarily, the first token may be a JWT token.

[0092] In one embodiment, as Figure 4 shown, the server may generate the first token through the following steps:

[0093] S410, call the control system to register a key pair for signing JWT tokens with the certificate issuing service, including a fourth public key and a fourth private key.

[0094] S420, the calling control system encrypts the identification information of the first host, the identification information of the first microservice, and the interface account of the verification interface matching the first microservice according to the fourth private key to obtain the first token.

[0095] Exemplarily, the identification information of the first host may be the identity identification number (identity, ID) of the first host, and the identification information of the first microservice may be the ID of the first microservice.

[0096] It should be understood that in addition to the JWT token, the first token may also adopt other types of tokens with similar functions, without limitation.

[0097] S320, the first host calls the trusted platform node to encrypt the first token to generate the second token.

[0098] Among them, the first host may call the host certificate in the trusted platform node to encrypt (encryption can also be called encoding) the first token to generate the second token.

[0099] In one implementation, the first host may call the host certificate of the first host in the trusted platform node to encode (encoding can also be called encryption) the first token to obtain the corresponding signature, called the second signature. And merge the second signature and the host certificate of the first host to generate the second token.

[0100] Exemplarily, the second token may be the cert token of the embodiment of the present application.

[0101] The host certificate may be a digital certificate that can distinguish hosts. As Figure 1 shown in the description of the host in the distributed system, each host is provided with a trusted platform node, and each trusted platform node deploys the host certificate of the corresponding host. The microservices in the host may call the host certificate in the trusted platform node to encrypt information. For example, the encoding of the first token introduced above. The process of deploying the host certificate may refer to the description of the distributed system above, and will not be elaborated here.

[0102] S330, the first host sends a first request with the second token as a credential to the server. Correspondingly, the server receives the first request from the first host with the second token as a credential.

[0103] Among them, the first request is used to request a third token, and the third token is used for the first microservice to access microservices other than the first microservice. The content of the first request can be set flexibly. Exemplarily, the content of the first request may include second information, and the second information includes the identification information of the requested host, the identification information of the microservice, and the interface account corresponding to the microservice.

[0104] S340. When the first request authenticated with the second token passes the verification, the server calls the verification interface to generate a third token based on the interface account parsed from the second token.

[0105] Among them, when the first request authenticated with the second token passes the verification, it indicates that the sender of the first request is indeed the legitimate first host recognized by the server. At this time, a third token serving the first host can be generated. The verification interface can be provided by the authentication management service in the server and can generate a third token based on the interface account parsed from the second token. Exemplarily, the third token can be a keystone token.

[0106] The server caches the third public key for signing the host certificate of the first host and the fourth public key for signing the first token. The server can verify whether the first request authenticated with the second token passes based on the third public key and the fourth public key.

[0107] Exemplarily, the first request passing the verification may include: the third public key can successfully decode the host certificate of the first host, the host certificate of the first host can successfully decode the second signature, the fourth public key can successfully decode the first token, and the first information matches the second information; where the first information is the identification information of the first host, the identification information of the first microservice, and the interface account used to generate the first token, and the second information is the identification information of the host requested by the first request, the identification information of the microservice, and the interface account.

[0108] In addition, if the first request authenticated with the second token fails the verification, it indicates that the sender of the first request is not the real first host, but the first request sent by other parties by forging the second token or other means. At this time, the third token is not generated to enhance the security of microservice management.

[0109] S350. The server sends the third token to the first host. Correspondingly, the first host receives the third token from the server.

[0110] Among them, the third token is used for the first microservice to access microservices other than the first microservice. In the microservice, there is a list of accessible accounts (which can be obtained from the server) of other microservices that can access itself and the corresponding interface accounts. The accessed microservice can decode the interface account in the third token sent by the first microservice. If the decoded interface account is in the list of accessible accounts deployed by the accessed microservice, the accessed microservice authorizes the first microservice to access. Otherwise, the first microservice is prohibited from accessing.

[0111] In the embodiments of the present application, a first token generated based on the identification information of the first host, the identification information of the first microservice, and the corresponding interface account, and a second token generated based on the host certificate are set between the server and the first host to determine whether to generate a third token for the first microservice of the first host to access microservices other than the first microservice, ensuring that the third token is issued to the verified first host and enhancing the security of microservice management. Further, the identity of the first microservice is authenticated by encrypting the interface account corresponding to the microservice with the third token, which will not cause the account password of the first microservice to be leaked. There is no need to place the clear-text account password of the first microservice on the host, reducing the risk of account password leakage. Moreover, the server pre-sets the mapping relationship between each microservice and the authentication management service account, avoiding the risk of a large explosion radius caused by password leakage when multiple hosts use the same password for the same microservice.

[0112] In one embodiment, as Figure 5 shown, before S350, the method may further include:

[0113] S510, the server obtains the microservice certificate corresponding to the first microservice according to the first request with the second token as the credential.

[0114] Among them, the microservice certificate is a digital certificate for distinguishing different microservices. The server can decode the second token to obtain the host name of the first host, the service name of the first microservice, and the interface account of the verification interface matching the first microservice, and call the certificate issuance service based on the host name of the first host, the service name of the first microservice, and the interface account to request a microservice certificate corresponding to the first microservice from the certificate authority. When the certificate authority generates the microservice certificate, it first generates a key pair, including a second public key and a second private key, and then encrypts the host name of the first host, the service name of the first microservice, and the interface account with the second private key to obtain the microservice certificate of the first microservice. And provide the second public key to the server for caching.

[0115] S520, the server sends the microservice certificate to the first host. Correspondingly, the first host receives the microservice certificate from the server.

[0116] Among them, after the server obtains the microservice certificate, it can send the microservice certificate to the corresponding host. Ensure that the host recognized by the server can hold the corresponding microservice certificate.

[0117] S530, the first host generates a fourth token according to the microservice certificate.

[0118] Among them, the first host can encrypt the expiration time of the microservice certificate with the first private key and microservice certificate generated by the first microservice to obtain the first signature; the expiration time of the microservice certificate can be flexibly set by the first microservice based on its own usage needs. Then, the first signature and the microservice certificate are synthesized to obtain the fourth token.

[0119] Exemplarily, the fourth token can be the cert token of the embodiment of the present application.

[0120] S540, the first host sends a second request to the server with the fourth token as the credential. Correspondingly, the server receives the second request from the first host with the fourth token as the credential.

[0121] Among them, the second request is used to request the third token. The second request with the fourth token as the credential can be used by the server to verify the legitimacy of the sender of the second request.

[0122] S550, the server verifies the second request with the fourth token as the credential.

[0123] Among them, if the second request with the fourth token as the credential is verified successfully, it indicates that the sender of the second request is indeed the legitimate first host recognized by the server, and then S350 is executed.

[0124] The following is an exemplary introduction to how to verify the second request with the fourth token as the credential:

[0125] Refer to the introduction of the server in the Figure 1 shown distributed system. The server caches the second public key issued by the issuing authority of the microservice certificate, which can be used to decode the microservice certificate. Exemplarily, the successful verification of the second request can include: the second public key can decode the microservice certificate, the microservice certificate checks that the first public key can decode the first signature, and the decoded expiration time is later than the current time.

[0126] In addition, if the second request with the fourth token as the credential fails to be verified, it indicates that the sender of the second request is not the first host recognized by the server, but a second request sent by other parties by forging the fourth token or other means. At this time, the server does not generate the third token to improve the security of microservice management.

[0127] In the embodiment of the present application, on the basis of the double verification of the first token and the second token, a fourth token based on the microservice certificate is introduced as the verification basis to further determine whether to send a third token for the first microservice of the first host to access microservices other than the first microservice, ensuring that the third token can be issued to the verified first host and further improving the security of microservice management.

[0128] In the embodiments of the present application, a mechanism is designed to use an authentication management service account encrypted with a token to replace the account password of a microservice to verify the microservice. A first token generated based on the identification information of the first host, the identification information of the first microservice, and the corresponding interface account, and a second token generated based on the host certificate are set between the server and the first host to determine whether to generate a third token for the first microservice of the first host to access microservices other than the first microservice, ensuring that the third token is issued to the verified first host and improving the security of microservice management. Further, the identity of the first microservice is authenticated by encrypting the interface account corresponding to the microservice with the third token, which will not cause the leakage of the account password of the first microservice. There is no need to place the plaintext account password of the first microservice on the host, reducing the risk of account password leakage. Moreover, the mapping relationship between each microservice and the authentication management service account avoids the risk of a large explosion radius caused by password leakage when multiple hosts use the same password for the same microservice.

[0129] The above mainly introduces the solution provided by the embodiments of the present application from the perspective of the execution logic of each step. It can be understood that in order to implement the above functions, the server includes the corresponding hardware structure and / or software module for executing each function. Those skilled in the art should easily realize that, combined with the algorithm steps of each example described in the embodiments disclosed in this article, the method of the embodiments of the present application can be implemented in the form of hardware, software, or a combination of hardware and computer software. Whether a certain function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0130] Figure 6 The structure diagram of a microservice management device 600 is shown, and the microservice management device is applied to the server. Figure 6In the device shown, each module has the functions corresponding to the steps in the method embodiment and can achieve the corresponding technical effects. The beneficial effects corresponding to the steps executed by each module can refer to the description of the corresponding steps in the method embodiment and will not be elaborated here. The functions can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. For example, the management device of the microservice includes: a sending module 610, configured to send a first token to the first host, the first token being generated by encrypting the identification information of the first host, the identification information of the first microservice, and the interface account of the verification interface matching the first microservice; a receiving module 620, configured to receive a first request with a second token as a credential, the second token being generated by encrypting the first token; a generating module 630, configured to, when the first request with the second token as a credential passes the verification, call the verification interface to generate a third token according to the interface account parsed from the second token; and the sending module 610, further configured to send the third token to the first host, the third token being used for the first microservice to access microservices other than the first microservice.

[0131] Figure 7 FIG. shows a structural diagram of a management device 700 of a microservice, and the management device of the microservice is applied to a first host. Figure 7 In the device shown, each module has the functions corresponding to the steps in the method embodiment and can achieve the corresponding technical effects. The beneficial effects corresponding to the steps executed by each module can refer to the description of the corresponding steps in the method embodiment and will not be elaborated here. The functions can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. For example, the management device of the microservice includes: a receiving module 710, configured to receive a first token, the first token being generated based on the identification information of the first host, the identification information of the first microservice, and the interface account of the verification interface matching the first microservice; an encryption module 720, configured to call a trusted platform node in the first host to encrypt the first token to generate a second token; a sending module 730, configured to send a first request with the second token as a credential to a server; the first request is used to generate a third token according to the interface account parsed from the second token; and the receiving module 710, further configured to receive the third token, the third token being used for the first microservice to access microservices other than the first microservice.

[0132] Among them, each of the above-introduced modules can be implemented by software or by hardware. Exemplarily, in the management device 600 of the microservice, next, taking the sending module 610 as an example, the implementation manner of the sending module 610 will be introduced. Similarly, the implementation manners of the receiving module 620 and the generating module 630 can refer to the implementation manner of the sending module 610.

[0133] It should be understood that the implementation manners of the modules in the microservice management device 700 can be implemented based on the same implementation principles as those of the modules in the microservice management device 600, which will not be elaborated here.

[0134] As an example of a software functional unit, the sending module 610 may include code running on a computing instance. Herein, the computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the above computing instance may be one or more. For example, the sending module 610 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers for running the code may be distributed in the same region or in different regions. Further, the multiple hosts / virtual machines / containers for running the code may be distributed in the same availability zone (AZ) or in different AZs, and each AZ includes one data center or multiple geographically proximate data centers. Usually, one region may include multiple AZs.

[0135] Similarly, the multiple hosts / virtual machines / containers for running the code may be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, one VPC is set within one region. For cross-region communication between two VPCs within the same region and between VPCs in different regions, a communication gateway needs to be set in each VPC, and the interconnection between VPCs is realized through the communication gateway.

[0136] As an example of a hardware functional unit, the sending module 610 may include at least one computing device, such as a server, etc. Alternatively, the sending module 610 may also be a device implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). Herein, the above PLD may be implemented by a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0137] The multiple computing devices included in the sending module 610 can be distributed in the same region or in different regions. The multiple computing devices included in the sending module 610 can be distributed in the same availability zone (AZ) or in different AZs. Similarly, the multiple computing devices included in the sending module 610 can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Among them, the multiple computing devices can be any combination of computing devices such as servers, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), and generic array logic (GALs).

[0138] It should be noted that in other embodiments, the sending module 610 can be used to execute any step in the data processing method, and the receiving module 620 and the generating module 630 can be used to execute any step in the data processing method. The steps to be implemented by the sending module 610, the receiving module 620, and the generating module 630 can be specified as needed. By implementing different steps in the data processing method through the sending module 610, the receiving module 620, and the generating module 630 respectively, all functions of the management device of the microservice can be realized.

[0139] This application also provides a computing device 100. As Figure 8 shown, the computing device 100 includes: a bus 102, a processor 104, a memory 106, and a communication interface 108. The processor 104, the memory 106, and the communication interface 108 communicate with each other through the bus 102. The computing device 100 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 100.

[0140] The bus 102 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of convenience of representation, Figure 8 only one line is shown in the figure, but it does not mean that there is only one bus or one type of bus. The bus 104 can include a path for transmitting information between various components of the computing device 100 (for example, the memory 106, the processor 104, and the communication interface 108).

[0141] The processor 104 may include any one or more of processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0142] The memory 106 may include volatile memory, such as random access memory (RAM). The processor 104 may also include non-volatile memory, such as read-only memory (ROM), flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0143] The memory 106 stores executable program code, and the processor 104 executes the executable program code to implement the functions of the foregoing sending module 610, receiving module 620, and generating module 630 respectively, thereby implementing the data processing method. That is, the memory 106 stores instructions for executing the data processing method.

[0144] Alternatively, the memory 106 stores executable code, and the processor 104 executes the executable code to implement the functions of the foregoing management device of the microservice respectively, thereby implementing the data processing method. That is, the memory 106 stores instructions for executing the data processing method.

[0145] The communication interface 103 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 100 and other devices or a communication network.

[0146] The embodiment of the present application further provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device may be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device may also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

[0147] As Figure 9 shown, the computing device cluster includes at least one computing device 100. The memory 106 in one or more of the computing devices 100 in the computing device cluster may store the same instructions for executing the data processing method.

[0148] In some possible implementations, the memory 106 of one or more computing devices 100 in the computing device cluster may also store some instructions for executing the data processing method respectively. In other words, the combination of one or more computing devices 100 can jointly execute the instructions for executing the data processing method.

[0149] It should be noted that the memories 106 in different computing devices 100 in the computing device cluster may store different instructions, which are respectively used to execute some functions of the management device of the microservices. That is, the instructions stored in the memories 106 of different computing devices 100 can implement the functions of one or more of the sending module 610, the receiving module 620, and the generating module 630.

[0150] In some possible implementations, one or more computing devices in the computing device cluster can be connected through a network. Among them, the network can be a wide area network or a local area network, etc. Figure 10 A possible implementation is shown. As Figure 10 shown, two computing devices 100A and 100B are connected through a network. Specifically, they are connected to the network through the communication interfaces in each computing device. In this type of possible implementation, the memory 106 in the computing device 100A stores instructions for executing the function of the sending module 610. At the same time, the memory 106 in the computing device 100B stores instructions for executing the functions of the receiving module 620 and the generating module 630.

[0151] Figure 10 The connection method between the computing device clusters shown is considered according to the needs of the data processing method provided in this application. Therefore, it is considered to hand over the functions implemented by the receiving module 620 and the generating module 630 to the computing device 100B for execution.

[0152] It should be understood that Figure 10 the functions of the computing device 100A shown can also be completed by multiple computing devices 100. Similarly, the functions of the computing device 100B can also be completed by multiple computing devices 100.

[0153] The embodiments of this application also provide another computing device cluster. The connection relationship between the computing devices in this computing device cluster can be similarly referred to Figure 9 and Figure 10 the connection method of the computing device cluster described above. The difference is that the memories 106 of one or more computing devices 100 in this computing device cluster may store the same instructions for executing the data processing method.

[0154] In some possible implementations, parts of the instructions for executing the data processing method may also be stored respectively in the memories 106 of one or more computing devices 100 in the computing device cluster. In other words, the combination of one or more computing devices 100 can jointly execute the instructions for executing the data processing method.

[0155] It should be noted that the memories 106 in different computing devices 100 in the computing device cluster may store different instructions for executing partial functions of the data detection system. That is to say, the instructions stored in the memories 106 of different computing devices 100 can implement the functions of the management device of the microservices.

[0156] The embodiment of the present application also provides a computer program product containing instructions. The computer program product may be software or a program product containing instructions that can run on a computing device or be stored in any available medium. When the computer program product runs on at least one computing device, it causes at least one computing device to execute the data processing method, or the data processing method.

[0157] The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium may be any available medium that a computing device can store or a data storage device such as a data center containing one or more available mediums. The available medium may be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid-state drive), etc. The computer-readable storage medium includes instructions, and the instructions direct the computing device to execute the data processing method, or direct the computing device to execute the data processing method.

[0158] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. A management method for microservices, characterized in that The method is applied to the server of a distributed computing system. The server is used to manage at least one host. The server deploys a first microservice on a first host, and the first host is any one of the at least one host. The method includes: Sending a first token to the first host, where the first token is generated by encrypting the identification information of the first host, the identification information of the first microservice, and the interface account of the verification interface matching the first microservice; Receiving a first request with a second token as a credential, where the second token is generated by encrypting the first token; When the first request with the second token as a credential passes the verification, calling the verification interface to generate a third token according to the interface account parsed from the second token; Sending the third token to the first host, where the third token is used for the first microservice to access microservices other than the first microservice.

2. The management method of microservices according to claim 1, wherein Before sending the third token to the first host, the method further includes: Obtaining a microservice certificate corresponding to the first microservice according to the first request; Sending the microservice certificate to the first host; Receiving a second request with a fourth token as a credential, where the fourth token includes the microservice certificate and a first signature, and the first signature is a signature obtained by encrypting the expiration time of the microservice certificate with a first private key generated by the first microservice and the microservice certificate; The sending the third token to the first host includes: When the second request passes the verification, sending the third token to the first host.

3. The management method of microservices according to claim 2, wherein The server caches a second public key issued by the issuing authority of the microservice certificate and a first public key generated by the first microservice. The passing of the verification of the second request includes: Successfully decoding the microservice certificate using the second public key, successfully decoding the first signature using the microservice certificate and the first public key, and the expiration time being later than the current time.

4. The management method of the microservice according to any one of claims 1-3, characterized in that The second token includes: A second signature obtained by encrypting the first token and the host certificate of the first host applied when encrypting the first token.

5. The management method of microservices according to claim 4, characterized in that The server caches a third public key for signing the host certificate of the first host and a fourth public key for signing the first token. The passing of the verification of the first request includes: Successfully decoding the host certificate of the first host using the third public key, successfully decoding the second signature using the host certificate of the first host, successfully decoding the first token using the fourth public key, and the first information matching the second information; where the first information is the identification information of the first host, the identification information of the first microservice, and the interface account used to generate the first token, and the second information is the identification information of the host requested by the first request, the identification information of the microservice, and the interface account.

6. A management method for microservices, characterized in that, The method is applied to a first host of a distributed computing system. The server in the distributed computing system is used to manage at least one host. The first host is any one of the at least one host. The server deploys a first microservice on the first host. The method includes: Receiving a first token, which is generated based on the identification information of the first host, the identification information of the first microservice, and the interface account of a verification interface matching the first microservice; Invoking a trusted platform node in the first host to encrypt the first token to generate a second token; Sending a first request with the second token as a credential to the server; the first request is used to generate a third token according to the interface account parsed from the second token; Receiving a third token, which is used for the first microservice to access microservices other than the first microservice.

7. The management method of microservices according to claim 6, characterized in that, Before receiving the third token, the method further includes: Receiving a microservice certificate; Encrypting the expiration time of the microservice certificate with a first secret key generated by the first microservice and the microservice certificate to obtain a first signature; Combining the first signature and the microservice certificate to obtain the fourth token; Sending a second request with the fourth token as a credential, and the second request is used to request the third token.

8. The management method of microservices according to claim 6 or 7, characterized in that, The invoking a trusted platform node in the first host to encrypt the first token to generate a second token includes: Invoking the trusted platform node to encrypt the first token according to the host certificate of the first host to obtain a second signature; Combining the host certificate of the first host and the second signature to obtain the second token.

9. A management device for microservices, characterized in that, The device is applied to the server of the distributed computing system. The server is used to manage at least one host. The server deploys a first microservice on a first host. The first host is any one of the at least one host. The device includes: A sending module, configured to send a first token to the first host, and the first token is generated by encrypting the identification information of the first host, the identification information of the first microservice, and the interface account of a verification interface matching the first microservice; A receiving module, configured to receive a first request with the second token as a credential, and the second token is generated by encrypting the first token; A generating module, configured to, when the first request with the second token as a credential passes the verification, invoke the verification interface to generate a third token according to the interface account parsed from the second token; The sending module is further configured to send the third token to the first host, and the third token is used for the first microservice to access microservices other than the first microservice.

10. The management device for microservices according to claim 9, characterized in that, The device further includes an obtaining module, configured to obtain a microservice certificate corresponding to the first microservice according to the first request before sending the third token to the first host; The sending module is configured to send the microservice certificate to the first host; The receiving module is configured to receive a second request vouched by a fourth token, where the fourth token includes the microservice certificate and a first signature, and the first signature is a signature obtained by encrypting the expiration time of the microservice certificate with a first private key generated by a first microservice and the microservice certificate; The sending module is specifically configured to: send the third token to the first host when the second request passes the verification.

11. The management device for microservices according to claim 10, characterized in that, The server caches a second public key issued by the issuing authority of the microservice certificate and a first public key generated by the first microservice. The passing of the verification of the second request includes: The microservice certificate can be successfully decoded using the second public key, the first signature can be successfully decoded using the microservice certificate and the first public key, and the expiration time is later than the current time.

12. The management device for microservices according to any one of claims 9-11, characterized in that, The second token includes: A second signature obtained by encrypting the first token and the host certificate of the first host applied when encrypting the first token.

13. The management device for microservices according to claim 12, characterized in that, The server caches a third public key for signing the host certificate of the first host and a fourth public key for signing the first token. The passing of the verification of the first request includes: The host certificate of the first host can be successfully decoded using the third public key, the second signature can be successfully decoded using the host certificate of the first host, the first token can be successfully decoded using the fourth public key, and the first information matches the second information; where the first information is the identification information of the first host, the identification information of the first microservice, and the interface account used to generate the first token, and the second information is the identification information of the host requested by the first request, the identification information of the microservice, and the interface account.

14. A management device for microservices, characterized in that, The apparatus is applied to a first host of a distributed computing system. The server in the distributed computing system is configured to manage at least one host. The first host is any one of the at least one host. The server deploys a first microservice on the first host. The apparatus includes: A receiving module, configured to receive a first token, where the first token is generated based on the identification information of the first host, the identification information of the first microservice, and the interface account of a verification interface matching the first microservice; An encryption module, configured to call a trusted platform node in the first host to encrypt the first token to generate a second token; A sending module, configured to send a first request vouched by the second token to the server; the first request is used to generate a third token according to the interface account parsed from the second token; The receiving module is further configured to receive a third token, where the third token is used for the first microservice to access microservices other than the first microservice.

15. The management device for microservices according to claim 14, characterized in that, The apparatus further includes a synthesis module; The receiving module is further configured to receive a microservice certificate before receiving the third token; The encryption module is further configured to encrypt the expiration time of the microservice certificate with a first secret key generated by the first microservice and the microservice certificate to obtain a first signature; The synthesis module is configured to synthesize the first signature and the microservice certificate to obtain the fourth token; The sending module is configured to send a second request using the fourth token as a credential, and the second request is used to request the third token.

16. The management device for microservices according to claim 14 or 15, characterized in that, The generating module is specifically configured to: Invoke the trusted platform node to encrypt the first token according to the host certificate of the first host to obtain a second signature; Combine the host certificate of the first host and the second signature to obtain the second token.

17. A cluster of computing devices, characterized in that, It includes at least one computing device, and each computing device includes a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1-8.

18. A computer program product comprising instructions, characterized in that, When the instructions are run by the computing device cluster, the computing device cluster executes the method according to any one of claims 1-8.

19. A computer-readable storage medium, characterized in that, It includes computer program instructions, and when the computer program instructions are executed by the computing device cluster, the computing device cluster executes the method according to any one of claims 1-8.

Images