Authentication method and device applied to kubernetes
By maintaining and authenticating access tokens for slave nodes on the Kubernetes master node, the security and complexity issues of slave node authentication in privacy computing are resolved, achieving simplified communication and enhanced security.
Patent Information
- Application Number
- CN202310325672.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-03-27
- Publication Date
- 2026-02-03
- Estimated Expiration
- 2043-03-27
AI Technical Summary
In privacy computing scenarios, Kubernetes slave nodes require authentication schemes to ensure security, but existing technologies are complex and pose a risk of access token leakage.
The master node maintains access tokens for each slave node through its gateway. Upon receiving a request from a slave node, the master node reads the token and passes it to the target component for authentication. This avoids storing the token in the slave node and uses a two-way transport layer security protocol or public-private key authentication for identity verification.
It simplifies master-slave node communication, reduces complexity, effectively prevents access token leakage, and ensures communication security.
Smart Images

Figure CN116366332B_ABST
Abstract
Description
Technical Field
[0001] This specification relates to one or more embodiments in the field of computer technology, and more particularly to an authentication method and apparatus for Kubernetes. Background Technology
[0002] Currently, the emergence of Kubernetes (k8s) has driven the popularization and implementation of popular technologies such as microservice architecture, making development, operation, and delivery increasingly simple. Therefore, more and more enterprises are using Kubernetes as their internal container orchestration platform to improve productivity.
[0003] In scenarios such as privacy computing, Kubernetes slave nodes are usually deployed among the participants. To ensure the security of privacy computing, the Kubernetes master node usually needs to authenticate the slave nodes.
[0004] Therefore, a simple and effective authentication scheme for slave nodes is needed. Summary of the Invention
[0005] This specification describes one or more embodiments of an authentication method and apparatus for Kubernetes, which can perform authentication of slave nodes simply and effectively.
[0006] According to the first aspect, an authentication method for Kubernetes is provided, wherein Kubernetes includes a master node and multiple slave nodes; the method includes:
[0007] The first gateway corresponding to the master node receives a first request from the second gateway corresponding to any first slave node, including the node identifier of the first slave node;
[0008] The first gateway authenticates the identity of the first slave node;
[0009] After the identity authentication is successful, the first gateway queries the access token set based at least on the node identifier to obtain the first token corresponding to the first slave node; the access token set stores multiple access tokens created for the multiple slave nodes respectively;
[0010] The first gateway adds the first token to the first request, obtains an update request, and provides the update request to the target component in the master node;
[0011] The target component authenticates the first slave node based on the first token.
[0012] According to a second aspect, an authentication device for Kubernetes is provided, wherein Kubernetes includes a master node and multiple slave nodes; the device is disposed on the master node and includes:
[0013] The receiving unit is configured to receive a first request from the second gateway corresponding to any first slave node, including the node identifier of the first slave node;
[0014] An authentication unit is used to authenticate the identity of the first slave node;
[0015] The query unit is used to query the access token set after the identity authentication is passed, based at least on the node identifier, to obtain the first token corresponding to the first slave node; the access token set stores multiple access tokens created for the multiple slave nodes respectively.
[0016] An adding unit is used to add the first token to the first request, obtain an update request, and provide the update request to the target component in the master node;
[0017] The authentication unit is used to authenticate the first slave node based on the first token.
[0018] According to a third aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of the first aspect.
[0019] According to a fourth aspect, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of the first aspect.
[0020] The authentication method for Kubernetes provided in one or more embodiments of this specification involves a first gateway corresponding to the master node maintaining access tokens for each slave node. After receiving an access request from a second gateway corresponding to a slave node, the first gateway reads the access token for that slave node and passes it to the target component in the master node for authentication. In other words, in this scheme, the master node does not need to provide the access token used for authentication to the slave nodes, thereby avoiding the risk of access token leakage and ensuring the security of master-slave node communication. Furthermore, since the slave nodes do not need to be aware of the access token, the complexity of master-slave node communication can be reduced. Attached Figure Description
[0021] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0022] Figure 1 This is a schematic diagram illustrating an implementation scenario of one embodiment disclosed in this specification;
[0023] Figure 2 A schematic diagram of an identity authentication method according to one embodiment is shown;
[0024] Figure 3 A schematic diagram illustrating an authentication method applied to Kubernetes according to one embodiment is shown.
[0025] Figure 4 A schematic diagram of an authentication device applied to Kubernetes according to one embodiment is shown. Detailed Implementation
[0026] The solution provided in this specification will now be described with reference to the accompanying drawings.
[0027] Figure 1 This is a schematic diagram illustrating an implementation scenario of one embodiment disclosed in this specification. Figure 1 In Kubernetes, a master node consists of a master node and multiple slave nodes. The master node includes a first gateway and a target component. The first gateway may maintain access tokens for each slave node. The target component, for example, can be an API Server, which is primarily responsible for communicating with other components or slave nodes. The slave nodes may include a second gateway, through which each slave node communicates with the master node.
[0028] Figure 1 In this system, any slave node can send an access request to the first gateway corresponding to the master node through the second gateway. The first gateway then obtains the access token corresponding to that slave node, adds it to the access request, and sends it to the target component. The target component can then authenticate the slave node based on the added access token.
[0029] It should be understood that Figure 1 This is merely an illustrative example. In practical applications, each slave node may also include agent components, etc., which are not limited in this specification.
[0030] In one embodiment, each of the aforementioned slave nodes is deployed in multiple participants in the privacy computing process. For example, node 1 is deployed in participant A, node 2 is deployed in participant B, and node N is deployed in participant X.
[0031] Of course, several slave nodes can also be deployed in the same participant. For example, node 1 and node 2 are both deployed in participant A, and node N is deployed in participant B, etc.
[0032] In the aforementioned privacy computing scenario, to ensure security, it is usually necessary to authenticate slave nodes. A necessary part of authenticating slave nodes is identity verification. Therefore, the following will first explain the identity verification methods for slave nodes.
[0033] Since the authentication methods for each slave node are similar, the following explanation will use any first slave node as an example.
[0034] One authentication method is based on Mutual Transport Layer Security (MTLS). MTLS is a protocol used at the transport layer. Therefore, when authenticating the first slave node, the execution result of MTLS can be directly read, and the authentication of the first slave node can be determined based on the read execution result.
[0035] Another authentication method is public-private key authentication, which is described in detail below:
[0036] Figure 2 A schematic diagram of an authentication method according to one embodiment is shown. Figure 2 As shown, the method may include the following steps:
[0037] In step S202, the second gateway corresponding to the first slave node sends its authorized public key to the first gateway corresponding to the master node.
[0038] Step S204: The first gateway establishes a correspondence between the first slave node and the authorized public key.
[0039] Step S206: The second gateway sends an access request to the first gateway.
[0040] Of course, in practical applications, the second gateway can also send a digital signature of the access request to the first gateway. This digital signature is obtained by signing the digest information of the access request using the private key corresponding to the aforementioned authorized public key.
[0041] In addition, the above access request may also include the node identifier of the first slave node, which may be, for example, the node name.
[0042] In step S208, the first gateway queries the above correspondence based on the node identifier to obtain the authorized public key of the first slave node.
[0043] In step S210, the first gateway uses the authorized public key to verify the digital signature of the access request. If the verification is successful, the identity authentication of the first slave node is passed; otherwise, the identity authentication of the first slave node fails.
[0044] Similarly, the first gateway can also maintain the correspondence between other slave nodes and their authorized public keys, and perform identity authentication on other slave nodes based on their respective authorized public keys, which will not be elaborated on here.
[0045] Figure 3 This diagram illustrates an authentication method applied to Kubernetes according to one embodiment. Figure 3 As shown, the method may include the following steps:
[0046] In step S302, the first gateway corresponding to the master node receives a first request from the second gateway corresponding to any first slave node, which includes the node identifier of the first slave node.
[0047] In one embodiment, the first request is used to request the use of a target resource under the namespace to which the first slave node belongs. The node identifier can be, for example, a node name.
[0048] In one embodiment, the first request may also include the result of the MTLS execution.
[0049] In another embodiment, the first gateway may also receive a digital signature of the first request from the second gateway. Specifically, the digital signature is obtained by signing the digest information of the access request using a private key corresponding to the aforementioned authorized public key.
[0050] Step S304: The first gateway authenticates the identity of the first slave node.
[0051] Here, either of the two authentication methods described above can be used for identity verification.
[0052] Specifically, if the first request includes the execution result of MTLS, the first gateway reads the execution result of MTLS from the first request and determines whether the authentication of the first slave node is successful based on the read execution result.
[0053] For example, if the above execution result indicates successful execution, then the authentication of the first slave node is confirmed to be successful; if the above execution result indicates failed execution, then the authentication of the first slave node is confirmed to be unsuccessful.
[0054] Of course, in practical applications, since MTLS is executed at the transport layer, the transport layer can directly intercept the first request if execution fails. In other words, the execution result of the MTLS in the first request received by the first gateway will always be successful.
[0055] Furthermore, when the first gateway also receives the digital signature of the first request from the second gateway, the first gateway can read the node identifier in the first request and query the correspondence between the node and the public key based on the node identifier, thereby obtaining the authorized public key of the first slave node. Then, using this authorized public key, the digital signature of the first request is verified. If the verification is successful, the authentication of the first slave node is determined to be successful; if the verification fails, the authentication of the first slave node is determined to be unsuccessful.
[0056] Step S306: After identity authentication is successful, the first gateway queries the access token set based at least on the node identifier to obtain the first token corresponding to the first slave node.
[0057] The aforementioned access token central storage contains multiple access tokens created separately for multiple slave nodes.
[0058] In one embodiment, the access tokens in the access token set are bound to the service account under the namespace of the corresponding node. For example, the first token is bound to the first service account. Thus, the first request also includes the first service account, and the first gateway queries the access token set based on the node identifier and the first service account.
[0059] In one embodiment, the aforementioned first service account is created through the following steps:
[0060] The first gateway sends a first call request to the target component (i.e., the API server) for the first interface, causing the target component to create a first service account. The first call request at least indicates the namespace to which the first slave node belongs.
[0061] In one example, the first interface includes the following interface parameters:
[0062] / api / v1 / namespaces / {namespace} / serviceaccounts
[0063] Here, api represents the fixed prefix of the interface, v1 represents the interface version, namespace represents the namespace to which the node belongs, and serviceaccounts represents the service account.
[0064] It should be noted that after the first gateway creates the first service account by calling the first interface mentioned above, it can send the first service account to the first slave node, so that the first slave node can carry the first service account in the first request.
[0065] It should be understood that after the first service account is created at the first gateway, a first token bound to the first service account can be created.
[0066] In one embodiment, the aforementioned first token is created through the following steps:
[0067] The first gateway sends a second call request to the target component (i.e., the API server) for the second interface, causing the target component to create a first token. The second call request at least indicates the namespace to which the first slave node belongs and the first service account.
[0068] In one example, the second interface includes the following interface parameters:
[0069] / api / v1 / namespaces / {namespace} / serviceaccounts / {serviceaccount} / token
[0070] Here, api represents the fixed prefix of the interface, v1 represents the interface version, namespace represents the namespace to which the node belongs, serviceaccounts represents the service account, and token represents the access token.
[0071] It should be noted that after the first gateway creates the first token by calling the second interface mentioned above, it can establish the correspondence between the node identifier of the first slave node, the first service account, and the first token, and add this correspondence to the access token set.
[0072] It should also be noted that the access tokens created through the embodiments of this specification may have a corresponding expiration time. Taking the first token as an example, the first gateway can determine whether the first token has expired. When the first token expires, it can re-call the aforementioned second interface to create an update token corresponding to the first service account. It should be understood that this update token also has an expiration time.
[0073] As can be seen, in this scheme, the access tokens corresponding to each slave node are created periodically.
[0074] In step S308, the first gateway adds the first token to the first request, obtains the update request, and provides the update request to the target component in the master node.
[0075] In one embodiment, a first token can be added to the header of the first request to obtain an update request.
[0076] Step S310: The target component authenticates the first slave node based on the first token.
[0077] As mentioned earlier, the first token is created by the first gateway by calling the target component's interface, so that the target component can perform authentication based on the first token.
[0078] Specifically, the target component can determine whether the first token meets predetermined conditions, which include at least one of the following: whether the first token has expired and whether the first token corresponds to a first service account. If the determination result indicates that the first token meets the predetermined conditions, the authentication of the first slave node is successful. If the determination result indicates that the first token does not meet the predetermined conditions, the authentication of the first slave node fails.
[0079] Of course, in practical applications, the above-mentioned predetermined conditions may also include whether the first token conforms to a predetermined format, etc., which are not limited in this specification.
[0080] It should be understood that after the first slave node is successfully authenticated, the target resources under the namespace to which the first slave node belongs can be used for target processing, etc.
[0081] In summary, the authentication method for Kubernetes provided in one or more embodiments of this specification involves the first gateway corresponding to the master node maintaining the access tokens corresponding to each slave node. After receiving an access request from the second gateway corresponding to a slave node, the first gateway reads the access token corresponding to that slave node and passes it to the target component in the master node for authentication. That is, in this scheme, the master node does not need to provide the access token used for authentication to the slave nodes, thereby avoiding the risk of access token leakage and ensuring the security of master-slave node communication. Furthermore, since the slave nodes do not need to be aware of the access token, the complexity of master-slave node communication can be reduced.
[0082] Corresponding to the authentication method applied to Kubernetes described above, one embodiment of this specification also provides an authentication device applied to Kubernetes, wherein Kubernetes includes a master node and multiple slave nodes, and the device is disposed on the master node. For example... Figure 4 As shown, the device may include:
[0083] The receiving unit 402 is used to receive a first request from the second gateway corresponding to any first slave node, including the node identifier of the first slave node;
[0084] Authentication unit 404 is used to authenticate the identity of the first slave node;
[0085] The query unit 406 is used to query the access token set, based at least on the node identifier, after successful authentication to obtain the first token corresponding to the first slave node. This access token set stores multiple access tokens created for each of the multiple slave nodes.
[0086] Add unit 408, which is used to add the first token in the first request, obtain the update request, and provide the update request to the target component in the master node;
[0087] The authentication unit 410 is used to authenticate the first slave node based on the first token.
[0088] In one embodiment, the first gateway maintains the authorized public key of the first slave node;
[0089] The receiving unit 402 is also configured to receive the digital signature of the first request from the second gateway;
[0090] Authentication unit 404 is specifically used for:
[0091] The digital signature of the first request is verified using the authorized public key;
[0092] If the verification is successful, the identity of the first slave node is authenticated.
[0093] In another embodiment, the authentication unit 404 is specifically used for:
[0094] Read the execution result of the MTLS (Mutual Transport Layer Security) protocol from the first request;
[0095] Based on the execution result of the read, determine whether the authentication of the first slave node is successful.
[0096] In one embodiment, the first token is bound to a first service account under the namespace to which the first slave node belongs; the first request also includes the first service account;
[0097] Query unit 406 is specifically used for:
[0098] Based on the node identifier and the first service account, query the access token set.
[0099] In one embodiment, the first service account is created by the first gateway by calling the first interface of the target component, and the call request for the first interface at least indicates the namespace to which the first slave node belongs;
[0100] The first token is created by the first gateway by calling the second interface of the target component. The call request to the second interface indicates at least the namespace to which the first slave node belongs and the first service account.
[0101] In one embodiment, the first token has an expiration date; the above-described apparatus further includes:
[0102] Calling unit 412 is used to re-call the second interface when it is determined that the first token has expired, so as to create an update token corresponding to the first service account.
[0103] In one embodiment, the authentication unit 410 is specifically used for:
[0104] Determine whether the first token meets the predetermined conditions, which include whether the first token has expired and whether the first token corresponds to the first service account, at least one of the above two items; if the determination result indicates that the first token meets the predetermined conditions, then the authentication of the first slave node is successful; if the determination result indicates that the first token does not meet the predetermined conditions, then the authentication of the first slave node is unsuccessful.
[0105] The functions of each functional module of the apparatus in the above embodiments of this specification can be implemented through the steps of the above method embodiments. Therefore, the specific working process of the apparatus provided in one embodiment of this specification will not be repeated here.
[0106] This specification provides an authentication device for Kubernetes, one embodiment of which can perform authentication of slave nodes simply and effectively.
[0107] According to another embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed in a computer, causes the computer to perform a combination Figure 2 or Figure 3 The method described.
[0108] According to another embodiment, a computing device is also provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements a combination... Figure 2 or Figure 3 The method described.
[0109] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device or medium embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.
[0110] The steps of the methods or algorithms described in conjunction with the disclosure in this specification can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disk, external hard disk, CD-ROM, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Alternatively, the ASIC can reside in a server. Of course, the processor and storage medium can also exist as discrete components in the server.
[0111] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in this invention can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium accessible to a general-purpose or special-purpose computer.
[0112] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.
[0113] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this specification. It should be understood that the above description is only a specific embodiment of this specification and is not intended to limit the scope of protection of this specification. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of this specification should be included within the scope of protection of this specification.
Claims
1. An authentication method applied to Kubernetes, wherein Kubernetes includes a master node and multiple slave nodes; the method includes: The first gateway corresponding to the master node receives a first request from the second gateway corresponding to any first slave node, which includes the node identifier of the first slave node and the first service account under the namespace to which the first slave node belongs. The first gateway authenticates the identity of the first slave node; After the identity authentication is successful, the first gateway queries the access token set based on the node identifier and the first service account to obtain the first token corresponding to the first slave node; The access token central storage contains multiple access tokens created for the multiple slave nodes respectively; The first gateway adds the first token to the first request, obtains an update request, and provides the update request to the target component in the master node; The target component authenticates the first slave node based on the first token.
2. The method according to claim 1, wherein, The first gateway maintains the authorized public key of the first slave node; The method further includes: Receive the digital signature of the first request from the second gateway; The first gateway performs identity authentication on the first slave node, including: The digital signature is verified using the authorized public key; If the verification is successful, the identity authentication of the first slave node is passed.
3. The method according to claim 1, wherein, The first gateway performs identity authentication on the first slave node, including: Read the execution result of the two-way transport layer security protocol MTLS from the first request; Based on the execution result of the read, determine whether the authentication of the first slave node is successful.
4. The method according to claim 1, wherein, The first service account is created by the first gateway by calling the first interface of the target component; The call request for the first interface should at least indicate the namespace to which the first slave node belongs; The first token is created by the first gateway by calling the second interface of the target component; The call request for the second interface should at least indicate the namespace to which the first slave node belongs and the first service account.
5. The method according to claim 4, wherein, The first token has an expiration date; The method further includes: When the first gateway determines that the first token has expired, it calls the second interface again to create an update token corresponding to the first service account.
6. The method according to claim 1, wherein, The target component authenticates the first slave node based on the first token, including: The target component determines whether the first token meets predetermined conditions; the predetermined conditions include whether the first token has expired and whether the first token corresponds to the first service account, at least one of the above two items; If the judgment result indicates that the first token meets the predetermined conditions, then the authentication of the first slave node is successful; If the determination result indicates that the first token does not meet the predetermined conditions, then the authentication of the first slave node will fail.
7. The method according to claim 1, wherein, The multiple slave nodes are deployed among the multiple participants in privacy computing.
8. An authentication device for Kubernetes, wherein Kubernetes includes a master node and multiple slave nodes; The device is located at the main node and includes: The receiving unit is configured to receive a first request from the second gateway corresponding to any first slave node, including the node identifier of the first slave node and the first service account under the namespace to which the first slave node belongs; An authentication unit is used to authenticate the identity of the first slave node; The query unit is used to query the access token set based on the node identifier and the first service account after the identity authentication is passed, and obtain the first token corresponding to the first slave node; the access token set stores multiple access tokens created for the multiple slave nodes respectively. An adding unit is used to add the first token to the first request, obtain an update request, and provide the update request to the target component in the master node; The authentication unit is used to authenticate the first slave node based on the first token.
9. A computer-readable storage medium having a computer program stored thereon, wherein, When the computer program is executed in the computer, it causes the computer to perform the method of any one of claims 1-7.
10. A computing device comprising a memory and a processor, wherein, The memory stores executable code, and when the processor executes the executable code, it implements the method of any one of claims 1-7.
Citation Information
Patent Citations
Micro service unified authentication method and gateway
CN108901022A
Proxy Authentication and Indirect Certificate Chaining
US20070245414A1