Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on April 19, 2024 has considered by the examiner.
Specification
The Specification submitted on April 19, 2024 has considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 10, 11 and 14 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 10 recites, the phrase "wishing" renders the claim(s) indefinite because the claim(s) include(s) elements not actually disclosed (those encompassed by "wishing"), thereby rendering the scope of the claim(s) unascertainable. The term “wishing” implies wants or desires and therefore scope of claims in rendered indefinite.
Claim 10 recites the limitation " the authenticity" in line 1.
Claim 11 recites the limitation "said certification token" in lines 7 and 12.
Claim 14 recites the limitation "said certification token" in lines 8 and 13.
There are insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-12 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Nainar et al. (US 20220103570 A1 –hereinafter –“Nainar”) in view of HASHMI et al. (US 20210157896 A1 –hereinafter—" SRIVASTAVA”).
As per claim 1: Nainar discloses a method of obtaining a token of an instantiation of a node cluster ([0016] In configurations, an attestation token may allow for providing a unidirectional integrity check within a cluster of nodes, or between nodes of different clusters) comprising
a master node and at least one compute node ([0024] a portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform. The portion 102 includes a master node 104 and two worker nodes 106a, 106b. As is known, the portion 102 may include many more worker nodes 106. The master node 104 includes an API-server 108 a. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108) comprising
at least one container intended to perform at least one task ([0006] FIGS. 1A, 1B, and 1C a portion of a container-orchestration system configured in accordance with the Kubernetes platform),
said method comprising the following implemented by said master node (0014: Verifying, by the first NSM, the second attestation token with the certificate authority (CA) server, wherein instantiating the first integrity verified path between the first pod and the first NSE pod is further based at least in part on the verifying the third attestation token with the CA server):
establishing a first instantiation certificate of said master node by means of a first set of certification parameters requested from a certification server ([0024] The master node 104 includes an API-server 108. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108. The worker node 106a includes a pod 112, which is a grouping of one or more containers (not illustrated) that provide services. The worker node 106a may include many more pods 112. The worker node 106b includes a network service endpoint (NSE) pod 114, which is a grouping of one or more containers (not illustrated)……. [0025] In configurations, when a pod, e.g., pod 112, wishes to obtain a service from another pod, the pod 112 may request an integrity verified path, e.g., the integrity verified path 116, to the NSE pod, e.g., the NSE pod 114, by sending a request for an integrity verified path to the local NSM, e.g., the NSM 110a. The request for the integrity verified path 116 that is sent to the NSM 110a may include various attributes);
obtaining at least one second instantiation certificate for said container of said compute node ([0019] various protocols are extended to request and send attestation tokens (such as address resolution protocol (ARP), bi-directional forwarding (BFD), control protocols, etc.). The techniques described herein leverage these protocols and let the network service mesh (NSM) query different entities that are involved at the control plane and data plane layer for the integrity verified path instantiation. The local NSM receiving the request for an integrity verified path from the requesting pod may request the attestation token from the NSE pod. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod. When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server. Once the validation is a success, the NSM may instantiate the integrity verified path between the requesting pod and the NSE pod and inject the integrity verified path into the requesting pod);
said second certificate being established by said compute node by means of at least one second set of certification parameters requested from the certification server ([0026]The request may include a second locally generated nonce generated by the NSM 110a. The NSE pod 114 may generate the second attestation token using the second nonce and provide the second attestation token to the NSM 110a. The NSM 110a may have the attestation token verified by the CA server 120, thereby confirming the integrity of the NSE pod 114. Since the attestation tokens verify the integrity of the pods 112, 114, the NSM 110a may instantiate the integrity verified path 116 between the pod 112 and the NSE pod 114 and inject the integrity verified path 116 into the pod 112);
transmitting, to said certification server, a request for generating said token of an instantiation of the node cluster, said request comprising said first certificate and said at least one second certificate ([0013] When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server); and
receiving said token of an instantiation of the node cluster generated by the certification server([0013] generating, by the first pod, the first attestation token, receiving, by the first NSM from the first pod, the first attestation token, and verifying, by the first NSM, the first attestation token with a certificate authority (CA) server. The method may additionally include providing, by the first NSM to the first NSE pod, a third request for a second attestation token, the third request including a second randomly generated nonce and receiving, by the first NSM from the first NSE pod, the second attestation token, the second attestation token being based at least in part on the second randomly generated nonce. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod).
Nainar does not explicitly disclose the establishing token is a certification token. HASHMI, in analogous art however, discloses the establishing token is a certification token ([0098] At Step 3, the sidecar 514 may be implemented to use the application identity token 522 to broker an identity token with enterprise scope 524. In an exemplary embodiment, the pod 510 is provided with a platform internal token 516. In an exemplary embodiment, the platform internal token 516 is a JWT. In another exemplary embodiment, the platform internal identity token 516 is in the form of at least one X.509 certificate. The platform internal token 516 is a signed token which identifies the bearer to a party which trusts the issuer. The platform internal token 516 may be directly or indirectly connected to an API Server 518. A keys API 520 may be provided with the platform internal token 516. The keys API 520 may include or be related to a chain of trust. [0099] In Step 4A, application tokens database 506 may receive or accept an application identity token 522 from Identity Helper Sidecar 514. In an exemplary embodiment, the application identity token 522 is a JWT. In Step 4B, application tokens database 506 may communicate information to Keys API 520. Application tokens database may have a cache which may include a Keys API URL for every cluster. The Keys API URL may be Secure Socket Layer (SSL) enabled with a certificate in the chain of trust. In Step 4C, application tokens database 506 may transmit an identity token with enterprise scope 524 to the Identity Helper Sidecar 514. A micro-service may be created to expose the public key that was used to sign the application identity token 522. Application tokens database 506 may have a certificate in a chain of trust. An SSL connection may be used in Steps 4A through 4C. The SSL connection that may be used in Steps 4A through 4C may use a certificate in the chain of trust. In Step 5, information may be determined by the Identity Helper Sidecar 514. The information determined by the Identity Helper Sidecar 514 may be used by Pod 510. [0100] Referring to FIG. 6, a second data flow diagram 600 is shown. According to an exemplary embodiment, Steps in validating an application identity token 522 are presented. A cluster 502 may include a certificate service 608, an application identity token 522, and an identity token with enterprise scope 524. The cluster 502 may be a Kubernetes cluster or any platform which supports a running instance of an application. The cluster 502 may be configured to communicate with application tokens database 506. Application tokens database 506 may be configured to communicate with application-specific data repository 504. The cluster 502 may create an entry in application-specific data repository 504 for the application identification and cluster combination. Application tokens database 506 may verify the application component and cluster combination before returning the identity token with enterprise scope 524).
HASHMI further discloses ([0104-0105] Referring to FIG. 7, a third data flow diagram 700 is shown. According to an exemplary embodiment, a cluster 502 (e.g., Kubemetes cluster or any platform which supports a running instance of an application) may be in communication with application-specific data repository 504. In an exemplary embodiment, the cluster 502 publishes a public key endpoint URL to application-specific data repository 504. The cluster 502 may include a cluster Certificate Authority (CA) 704 that is configured to issue a plurality of certificates, including, but not limited to, a controller-manager certificate 706, an API-server certificate 708, and a service-account certificate 710. There may be relevant API Server Parameters. For example, relevant API Server Parameters may include, but are not limited to, a service account key file, a service account signing key file, a service account issuer, and a service account API audience. The service account key file may relate to a private key used to sign a service account application identity token. The service account signing key file may relate to a public key used to sign a service account application identity token. The service account issuer may relate to an issuer attribute in the certificate used to sign the application identity token. The service account API audience may relate to at least one service account token that may be transmitted via a projected volume method. The at least one service account token may have a tag with a specified audience value). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations disclosed by Nainar to include the establishing token is a certification token. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to facilitate an identification of an application that runs on a platform by establishing the identity of the applications that run on the platform and making the identity available, for example, to application containers, nodes, workers, minions, or machines where workloads are deployed such that the applications can seamlessly connect to other services without the need for authentication such as passwords as suggested by HASHMI ([0005]).
As per claim 2: Nainar in view of HASHMI discloses the method of obtaining a certification token according to claim 1, wherein the sets of certification parameters requested from the certification server comprise at least one item of timestamping information and one hash of an identifier of said certification server (HASHMI [0089] According to an exemplary embodiment, at least one of the platform-local identity token, the token describing the application owner, and the enterprise token describing the identity of the application is a time-limited token, i.e., is a token that is valid for a predetermined amount of time. Tune-limited tokens may be replaced with another token. When a token has expired or when a token is soon to expire, an automated process may replace an expired or soon-to-be expired token. A process for replacing a token may be similar to the automated process that originally issued the token. [0093] The scope may include information relating to two or more parties. An application identity token 522 may include information such as, for example, an issuer (i.e., the cluster from which the application identity token 522 is issued), an expiration time (i.e., when the token expires), an issuance time (i.e., when the token was issued), a name space, a secret name, a service account name, a service account unique identifier (UID), and a pod name).
As per claim 3: Nainar in view of HASHMI discloses the method of obtaining a certification token according to claim 2, wherein the requested sets of certification parameters also include an item of location information (HASHMI [0041] The computer system 102 may also include at least one input device 110, such as a keyboard, a touch-sensitive input screen or pad, a speech input, a mouse, a remote control device having a wireless keypad, a microphone coupled to a speech recognition engine, a camera such as a video camera or still camera, a cursor control device, a global positioning system (GPS) device, an altimeter, a gyroscope, an accelerometer, a proximity sensor, or any combination thereof. Those skilled in the art appreciate that various embodiments of the computer system 102 may include multiple input devices 110. Moreover, those skilled in the art further appreciate that the above-listed, exemplary input devices 110 are not meant to be exhaustive and that the computer system 102 may include any additional, or alternative, input devices 110).
As per claim 4: Nainar in view of HASHMI discloses the method of obtaining a certification token according to claim 2, wherein the requested sets of certification parameters are signed by means of a private cryptographic key of the certification server (HASHMI [0092] Even though a cloud platform may have a trusted place in the infrastructure, the cloud platform's identity may be verified by the Kerberos infrastructure for each request. In an exemplary embodiment, the Kerberos infrastructure may verify the identity of the platform based on each entity or deployment of the cloud infrastructure, which may be registered in a central application registry. Any token that the cloud platform presents to the Kerberos infrastructure may be signed using the platform's private key. The corresponding public key may be retrieved from an endpoint that is looked up in the central application registry).
As per claim 5: Nainar in view of HASHMI discloses the method of obtaining a certification token according to claim 1, wherein the first certificate is also established from data relating to said master node and belonging to a group comprising: a network address of the master node; a physical address of the master node; at least one identifier of a model of the hardware constituting the master node; at least one identifier of at least one software executed by the master node; an identifier of an operator orchestrating said node cluster; at least one identifier of at least one task performed by at least one container of at least one compute node of said cluster; an identifier of at least one service provider on behalf of which a container performs a task; and a hash of at least one of the above data (HASHMI: [0010] At least one of the platform-local identity token and the enterprise token describing the identity of the application may include at least one of an application identifier, a platform instance identifier, and a platform tenant space identifier. [0081] At step S412, the PAI module 302 issues a platform-local identity token to the instance of the application. In an exemplary embodiment, the PAI module 302 issues the application instance with the platform-local identity token. According to an exemplary embodiment, the platform-local identity token may be time-limited and/or may include at least one of an application identifier, a platform instance identifier, and a platform tenant space identifier. In an exemplary embodiment, the platform may issue the application instance with a platform-local identity token and the application may initially use the platform-local identity token to authenticate a request to an “identity provider” running in the platform's context for the platform to issue a token that describes the application owner. [0093] An application identity token 522 may include information such as, for example, an issuer (i.e., the cluster from which the application identity token 522 is issued), an expiration time (i.e., when the token expires), an issuance time (i.e., when the token was issued), a name space, a secret name, a service account name, a service account unique identifier (UID), and a pod name).
As per claim 6: Nainar in view of HASHMI discloses the method of obtaining a certification token according to claim 1, wherein the certification token comprises at least one hash of the first certificate and the second certificate timestamped by the certification server (HASHMI [0099]: The Keys API URL may be Secure Socket Layer (SSL) enabled with a certificate in the chain of trust. In Step 4C, application tokens database 506 may transmit an identity token with enterprise scope 524 to the Identity Helper Sidecar 514. A micro-service may be created to expose the public key that was used to sign the application identity token 522. Application tokens database 506 may have a certificate in a chain of trust. An SSL connection may be used in Steps 4A through 4C. The SSL connection that may be used in Steps 4A through 4C may use a certificate in the chain of trust. In Step 5, information may be determined by the Identity Helper Sidecar 514. The information determined by the Identity Helper Sidecar 514 may be used by Pod 510).
As per claim 7: Nainar in view of HASHMI discloses the method of obtaining a certification token according to claim 6, wherein the certification token is signed by means of the private cryptographic key of the certification server (HASHMI [0105] The Keys API URL may be Secure Socket Layer (SSL) enabled with a certificate in the chain of trust. In Step 4C, application tokens database 506 may transmit an identity token with enterprise scope 524 to the Identity Helper Sidecar 514. A micro-service may be created to expose the public key that was used to sign the application identity token 522. Application tokens database 506 may have a certificate in a chain of trust. An SSL connection may be used in Steps 4A through 4C. The SSL connection that may be used in Steps 4A through 4C may use a certificate in the chain of trust. In Step 5, information may be determined by the Identity Helper Sidecar 514. The information determined by the Identity Helper Sidecar 514 may be used by Pod 510).
As per claim 8: Nainar discloses a method of establishing a token for an instantiation of a node cluster comprising ([0016] In configurations, an attestation token may allow for providing a unidirectional integrity check within a cluster of nodes, or between nodes of different clusters) a master node and at least one compute node ( [0024] a portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform. The portion 102 includes a master node 104 and two worker nodes 106a, 106b. As is known, the portion 102 may include many more worker nodes 106. The master node 104 includes an API-server 108 a. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108) comprising
at least one container intended to execute at least one task ([0006] FIGS. 1A, 1B, and 1C a portion of a container-orchestration system configured in accordance with the Kubernetes platform), said method comprising the following steps implemented by a certification server (0014: Verifying, by the first NSM, the second attestation token with the certificate authority (CA) server, wherein instantiating the first integrity verified path between the first pod and the first NSE pod is further based at least in part on the verifying the third attestation token with the CA server):
transmitting of a first set of certification parameters to said master node ([0024] The master node 104 includes an API-server 108. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108. The worker node 106a includes a pod 112, which is a grouping of one or more containers (not illustrated) that provide services. The worker node 106a may include many more pods 112. The worker node 106b includes a network service endpoint (NSE) pod 114, which is a grouping of one or more containers (not illustrated)……. [0025] In configurations, when a pod, e.g., pod 112, wishes to obtain a service from another pod, the pod 112 may request an integrity verified path, e.g., the integrity verified path 116, to the NSE pod, e.g., the NSE pod 114, by sending a request for an integrity verified path to the local NSM, e.g., the NSM 110a. The request for the integrity verified path 116 that is sent to the NSM 110a may include various attributes);
transmitting at least one second set of certification parameters to at least one container of said compute node ([0019] various protocols are extended to request and send attestation tokens (such as address resolution protocol (ARP), bi-directional forwarding (BFD), control protocols, etc.). The techniques described herein leverage these protocols and let the network service mesh (NSM) query different entities that are involved at the control plane and data plane layer for the integrity verified path instantiation. The local NSM receiving the request for an integrity verified path from the requesting pod may request the attestation token from the NSE pod. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod. When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server. Once the validation is a success, the NSM may instantiate the integrity verified path between the requesting pod and the NSE pod and inject the integrity verified path into the requesting pod);
receiving, from said master node, a request for generating said token of an instantiation of the node cluster ([0021] In configurations, the NSM may contain a table of integrity verified endpoints, e.g., pods. Thus, when a request is made for an integrity verified path to a particular NSE pod, the NSM may check the table and determine if the requesting pod and/or the NSE pod are already verified, the NSM may instantiate the integrity verified path between the requesting pod and the NSE pod. In order to maintain the integrity of the various pods, the NSM interface may periodically re-validate pods within the table. The re-validation may include providing a locally generated nonce, sending it to the pod with a request for an attestation token, and then verifying the attestation token received from the pod with the CA server. A re-validation interval may define a periodic/continuous re-validation time interval), said request comprising
a first instantiation certificate of said master node established by means of the first set of certification parameters ([0021] The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114) and
at least one second instantiation certificate of said container established by means of the second set of certification parameters ([0026]The request may include a second locally generated nonce generated by the NSM 110a. The NSE pod 114 may generate the second attestation token using the second nonce and provide the second attestation token to the NSM 110a. The NSM 110a may have the attestation token verified by the CA server 120, thereby confirming the integrity of the NSE pod 114. Since the attestation tokens verify the integrity of the pods 112, 114, the NSM 110a may instantiate the integrity verified path 116 between the pod 112 and the NSE pod 114 and inject the integrity verified path 116 into the pod 112);
generating said token of an instantiation of the node cluster by means of said first certificate and said at least one second certificate ([0013] generating, by the first pod, the first attestation token, receiving, by the first NSM from the first pod, the first attestation token, and verifying, by the first NSM, the first attestation token with a certificate authority (CA) server. The method may additionally include providing, by the first NSM to the first NSE pod, a third request for a second attestation token, the third request including a second randomly generated nonce and receiving, by the first NSM from the first NSE pod, the second attestation token, the second attestation token being based at least in part on the second randomly generated nonce. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod); and
transmitting said token of an instantiation of the node cluster to said master node ([0013] When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server).
Nainar does not explicitly disclose the establishing token is a certification token. HASHMI, in analogous art however, discloses the establishing token is a certification token ([0098] At Step 3, the sidecar 514 may be implemented to use the application identity token 522 to broker an identity token with enterprise scope 524. In an exemplary embodiment, the pod 510 is provided with a platform internal token 516. In an exemplary embodiment, the platform internal token 516 is a JWT. In another exemplary embodiment, the platform internal identity token 516 is in the form of at least one X.509 certificate. The platform internal token 516 is a signed token which identifies the bearer to a party which trusts the issuer. The platform internal token 516 may be directly or indirectly connected to an API Server 518. A keys API 520 may be provided with the platform internal token 516. The keys API 520 may include or be related to a chain of trust. [0099] In Step 4A, application tokens database 506 may receive or accept an application identity token 522 from Identity Helper Sidecar 514. In an exemplary embodiment, the application identity token 522 is a JWT. In Step 4B, application tokens database 506 may communicate information to Keys API 520. Application tokens database may have a cache which may include a Keys API URL for every cluster. The Keys API URL may be Secure Socket Layer (SSL) enabled with a certificate in the chain of trust. In Step 4C, application tokens database 506 may transmit an identity token with enterprise scope 524 to the Identity Helper Sidecar 514. A micro-service may be created to expose the public key that was used to sign the application identity token 522. Application tokens database 506 may have a certificate in a chain of trust. An SSL connection may be used in Steps 4A through 4C. The SSL connection that may be used in Steps 4A through 4C may use a certificate in the chain of trust. In Step 5, information may be determined by the Identity Helper Sidecar 514. The information determined by the Identity Helper Sidecar 514 may be used by Pod 510. [0100] Referring to FIG. 6, a second data flow diagram 600 is shown. According to an exemplary embodiment, Steps in validating an application identity token 522 are presented. A cluster 502 may include a certificate service 608, an application identity token 522, and an identity token with enterprise scope 524. The cluster 502 may be a Kubernetes cluster or any platform which supports a running instance of an application. The cluster 502 may be configured to communicate with application tokens database 506. Application tokens database 506 may be configured to communicate with application-specific data repository 504. The cluster 502 may create an entry in application-specific data repository 504 for the application identification and cluster combination. Application tokens database 506 may verify the application component and cluster combination before returning the identity token with enterprise scope 524.
HASHMI further discloses ([0104-0105] Referring to FIG. 7, a third data flow diagram 700 is shown. According to an exemplary embodiment, a cluster 502 (e.g., Kubemetes cluster or any platform which supports a running instance of an application) may be in communication with application-specific data repository 504. In an exemplary embodiment, the cluster 502 publishes a public key endpoint URL to application-specific data repository 504. The cluster 502 may include a cluster Certificate Authority (CA) 704 that is configured to issue a plurality of certificates, including, but not limited to, a controller-manager certificate 706, an API-server certificate 708, and a service-account certificate 710. There may be relevant API Server Parameters. For example, relevant API Server Parameters may include, but are not limited to, a service account key file, a service account signing key file, a service account issuer, and a service account API audience. The service account key file may relate to a private key used to sign a service account application identity token. The service account signing key file may relate to a public key used to sign a service account application identity token. The service account issuer may relate to an issuer attribute in the certificate used to sign the application identity token. The service account API audience may relate to at least one service account token that may be transmitted via a projected volume method. The at least one service account token may have a tag with a specified audience value). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations disclosed by Nainar to include the establishing token is a certification token. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to facilitate an identification of an application that runs on a platform by establishing the identity of the applications that run on the platform and making the identity available, for example, to application containers, nodes, workers, minions, or machines where workloads are deployed such that the applications can seamlessly connect to other services without the need for authentication such as passwords as suggested by HASHMI ([0005]).
As per claim 9: Nainar discloses a method of establishing a certificate of an instantiation intended to execute at least one task ([0006] FIGS. 1A, 1B, and 1C a portion of a container-orchestration system configured in accordance with the Kubernetes platform), said container belonging to a compute node of a node cluster ([0016] In configurations, an attestation token may allow for providing a unidirectional integrity check within a cluster of nodes, or between nodes of different clusters) comprising
a master node and a plurality of compute nodes ([0024] a portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform. The portion 102 includes a master node 104 and two worker nodes 106a, 106b. As is known, the portion 102 may include many more worker nodes 106. The master node 104 includes an API-server 108 a. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108),
said method comprising the following implemented by a container (0014: Verifying, by the first NSM, the second attestation token with the certificate authority (CA) server, wherein instantiating the first integrity verified path between the first pod and the first NSE pod is further based at least in part on the verifying the third attestation token with the CA server):
establishing a certificate instantiation by means of a set of certification parameters requested from a certification server([0024] The master node 104 includes an API-server 108. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108. The worker node 106a includes a pod 112, which is a grouping of one or more containers (not illustrated) that provide services. The worker node 106a may include many more pods 112. The worker node 106b includes a network service endpoint (NSE) pod 114, which is a grouping of one or more containers (not illustrated)……. [0025] In configurations, when a pod, e.g., pod 112, wishes to obtain a service from another pod, the pod 112 may request an integrity verified path, e.g., the integrity verified path 116, to the NSE pod, e.g., the NSE pod 114, by sending a request for an integrity verified path to the local NSM, e.g., the NSM 110a. The request for the integrity verified path 116 that is sent to the NSM 110a may include various attributes); and
transmitting, to said master node, said certificate ([0013] When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server).
Nainar does not explicitly disclose said instantiation is an instantiation of at least one container. HASHMI, in analogous art however, discloses said instantiation is an instantiation of at least one container ([0104-0105] Referring to FIG. 7, a third data flow diagram 700 is shown. According to an exemplary embodiment, a cluster 502 (e.g., Kubemetes cluster or any platform which supports a running instance of an application) may be in communication with application-specific data repository 504. In an exemplary embodiment, the cluster 502 publishes a public key endpoint URL to application-specific data repository 504. The cluster 502 may include a cluster Certificate Authority (CA) 704 that is configured to issue a plurality of certificates, including, but not limited to, a controller-manager certificate 706, an API-server certificate 708, and a service-account certificate 710. There may be relevant API Server Parameters. For example, relevant API Server Parameters may include, but are not limited to, a service account key file, a service account signing key file, a service account issuer, and a service account API audience. The service account key file may relate to a private key used to sign a service account application identity token. The service account signing key file may relate to a public key used to sign a service account application identity token. The service account issuer may relate to an issuer attribute in the certificate used to sign the application identity token. The service account API audience may relate to at least one service account token that may be transmitted via a projected volume method. The at least one service account token may have a tag with a specified audience value). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations disclosed by Nainar to include said instantiation is an instantiation of at least one container. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to facilitate an identification of an application that runs on a platform by establishing the identity of the applications that run on the platform and making the identity available, for example, to application containers, nodes, workers, minions, or machines where workloads are deployed such that the applications can seamlessly connect to other services without the need for authentication such as passwords as suggested by HASHMI ([0005]).
As per claim 10: Nainar discloses a method of verifying the authenticity of a token of an instantiation of a node cluster comprising ([0016] In configurations, an attestation token may allow for providing a unidirectional integrity check within a cluster of nodes, or between nodes of different clusters)
a master node and at least one compute node ([0024] a portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform. The portion 102 includes a master node 104 and two worker nodes 106a, 106b. As is known, the portion 102 may include many more worker nodes 106. The master node 104 includes an API-server 108 a. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108) comprising
at least one container intended to execute at least one task ([0006] FIGS. 1A, 1B, and 1C a portion of a container-orchestration system configured in accordance with the Kubernetes platform),
said method comprising the following steps implemented by an item of equipment wishing to access a service implemented by said node cluster (0014: Verifying, by the first NSM, the second attestation token with the certificate authority (CA) server, wherein instantiating the first integrity verified path between the first pod and the first NSE pod is further based at least in part on the verifying the third attestation token with the CA server):
transmitting, to said master node, a request for establishing a session with said node cluster ([0019] The local NSM receiving the request for an integrity verified path from the requesting pod may request the attestation token from the NSE pod. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod. When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server);
receiving a signalling message relating to the establishment of said session ([0025] The request for the integrity verified path 116 that is sent to the NSM 110a may include various attributes. For example, the request may include attributes such as, for example, a label (e.g., conditions for selecting a NSE for providing a desired service), a network service (e.g., the type of desired service), and a color (e.g., quality of service). In configurations, the request may also include integrity attributes including integrity-verified (an indication if the node that includes the NSE pod should be integrity verified) and continuous (an indication if the node that includes the NSE pod needs to only initially be integrity verified or if the node should be periodically re-validated for integrity, e.g., the node should be continuously integrity verified) further comprising
said token established by a certification server by means of a first instantiation certificate of said master node established by means of a first set of certification parameters requested from the certification server ([0024] The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114) ; and
at least one second instantiation certificate of said container established by means of a second set of certification parameters requested from the certification server([0026]The request may include a second locally generated nonce generated by the NSM 110a. The NSE pod 114 may generate the second attestation token using the second nonce and provide the second attestation token to the NSM 110a. The NSM 110a may have the attestation token verified by the CA server 120, thereby confirming the integrity of the NSE pod 114. Since the attestation tokens verify the integrity of the pods 112, 114, the NSM 110a may instantiate the integrity verified path 116 between the pod 112 and the NSE pod 114 and inject the integrity verified path 116 into the pod 112); and
verifying the authenticity of said token with said certification server ([0013] generating, by the first pod, the first attestation token, receiving, by the first NSM from the first pod, the first attestation token, and verifying, by the first NSM, the first attestation token with a certificate authority (CA) server. The method may additionally include providing, by the first NSM to the first NSE pod, a third request for a second attestation token, the third request including a second randomly generated nonce and receiving, by the first NSM from the first NSE pod, the second attestation token, the second attestation token being based at least in part on the second randomly generated nonce. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod).
Nainar does not explicitly disclose the establishing token is a certification token. HASHMI, in analogous art however, discloses the establishing token is a certification token ([0098] At Step 3, the sidecar 514 may be implemented to use the application identity token 522 to broker an identity token with enterprise scope 524. In an exemplary embodiment, the pod 510 is provided with a platform internal token 516. In an exemplary embodiment, the platform internal token 516 is a JWT. In another exemplary embodiment, the platform internal identity token 516 is in the form of at least one X.509 certificate. The platform internal token 516 is a signed token which identifies the bearer to a party which trusts the issuer. The platform internal token 516 may be directly or indirectly connected to an API Server 518. A keys API 520 may be provided with the platform internal token 516. The keys API 520 may include or be related to a chain of trust. [0099] In Step 4A, application tokens database 506 may receive or accept an application identity token 522 from Identity Helper Sidecar 514. In an exemplary embodiment, the application identity token 522 is a JWT. In Step 4B, application tokens database 506 may communicate information to Keys API 520. Application tokens database may have a cache which may include a Keys API URL for every cluster. The Keys API URL may be Secure Socket Layer (SSL) enabled with a certificate in the chain of trust. In Step 4C, application tokens database 506 may transmit an identity token with enterprise scope 524 to the Identity Helper Sidecar 514. A micro-service may be created to expose the public key that was used to sign the application identity token 522. Application tokens database 506 may have a certificate in a chain of trust. An SSL connection may be used in Steps 4A through 4C. The SSL connection that may be used in Steps 4A through 4C may use a certificate in the chain of trust. In Step 5, information may be determined by the Identity Helper Sidecar 514. The information determined by the Identity Helper Sidecar 514 may be used by Pod 510. [0100] Referring to FIG. 6, a second data flow diagram 600 is shown. According to an exemplary embodiment, Steps in validating an application identity token 522 are presented. A cluster 502 may include a certificate service 608, an application identity token 522, and an identity token with enterprise scope 524. The cluster 502 may be a Kubernetes cluster or any platform which supports a running instance of an application. The cluster 502 may be configured to communicate with application tokens database 506. Application tokens database 506 may be configured to communicate with application-specific data repository 504. The cluster 502 may create an entry in application-specific data repository 504 for the application identification and cluster combination. Application tokens database 506 may verify the application component and cluster combination before returning the identity token with enterprise scope 524.
HASHMI further discloses ([0104-0105] Referring to FIG. 7, a third data flow diagram 700 is shown. According to an exemplary embodiment, a cluster 502 (e.g., Kubemetes cluster or any platform which supports a running instance of an application) may be in communication with application-specific data repository 504. In an exemplary embodiment, the cluster 502 publishes a public key endpoint URL to application-specific data repository 504. The cluster 502 may include a cluster Certificate Authority (CA) 704 that is configured to issue a plurality of certificates, including, but not limited to, a controller-manager certificate 706, an API-server certificate 708, and a service-account certificate 710. There may be relevant API Server Parameters. For example, relevant API Server Parameters may include, but are not limited to, a service account key file, a service account signing key file, a service account issuer, and a service account API audience. The service account key file may relate to a private key used to sign a service account application identity token. The service account signing key file may relate to a public key used to sign a service account application identity token. The service account issuer may relate to an issuer attribute in the certificate used to sign the application identity token. The service account API audience may relate to at least one service account token that may be transmitted via a projected volume method. The at least one service account token may have a tag with a specified audience value). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations disclosed by Nainar to include the establishing token is a certification token. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to facilitate an identification of an application that runs on a platform by establishing the identity of the applications that run on the platform and making the identity available, for example, to application containers, nodes, workers, minions, or machines where workloads are deployed such that the applications can seamlessly connect to other services without the need for authentication such as passwords as suggested by HASHMI ([0005]).
As per claim 11: Nainar discloses a master node of a node cluster also ([0016] In configurations, an attestation token may allow for providing a unidirectional integrity check within a cluster of nodes, or between nodes of different clusters) comprising at least one compute node comprising
at least one container intended to execute at least one task ([0006] FIGS. 1A, 1B, and 1C a portion of a container-orchestration system configured in accordance with the Kubernetes platform), said master node ([0024] a portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform. The portion 102 includes a master node 104 and two worker nodes 106a, 106b. As is known, the portion 102 may include many more worker nodes 106. The master node 104 includes an API-server 108 a. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108)comprising
at least one processor configured to:
establish a first instantiation certificate of said master node by means of a first set of certification parameters requested from a certification server ([0026]The request may include a second locally generated nonce generated by the NSM 110a. The NSE pod 114 may generate the second attestation token using the second nonce and provide the second attestation token to the NSM 110a. The NSM 110a may have the attestation token verified by the CA server 120, thereby confirming the integrity of the NSE pod 114. Since the attestation tokens verify the integrity of the pods 112, 114, the NSM 110a may instantiate the integrity verified path 116 between the pod 112 and the NSE pod 114 and inject the integrity verified path 116 into the pod 112);
obtain at least one second instantiation certificate for said container of said compute node ([0019] various protocols are extended to request and send attestation tokens (such as address resolution protocol (ARP), bi-directional forwarding (BFD), control protocols, etc.). The techniques described herein leverage these protocols and let the network service mesh (NSM) query different entities that are involved at the control plane and data plane layer for the integrity verified path instantiation. The local NSM receiving the request for an integrity verified path from the requesting pod may request the attestation token from the NSE pod. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod. When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server. Once the validation is a success, the NSM may instantiate the integrity verified path between the requesting pod and the NSE pod and inject the integrity verified path into the requesting pod),
said second certificate being established by said compute node by means of at least one second set of certification parameters requested from the certification server ([0026]The request may include a second locally generated nonce generated by the NSM 110a. The NSE pod 114 may generate the second attestation token using the second nonce and provide the second attestation token to the NSM 110a. The NSM 110a may have the attestation token verified by the CA server 120, thereby confirming the integrity of the NSE pod 114. Since the attestation tokens verify the integrity of the pods 112, 114, the NSM 110a may instantiate the integrity verified path 116 between the pod 112 and the NSE pod 114 and inject the integrity verified path 116 into the pod 112);
transmit, to said certification server, a request for generating said token of an instantiation of the node cluster ([0013] When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server), said request comprising
said first certificate and said at least one second certificate (The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114) ; and
receive said token of an instantiation of the node cluster generated by the certification server ([0013] generating, by the first pod, the first attestation token, receiving, by the first NSM from the first pod, the first attestation token, and verifying, by the first NSM, the first attestation token with a certificate authority (CA) server. The method may additionally include providing, by the first NSM to the first NSE pod, a third request for a second attestation token, the third request including a second randomly generated nonce and receiving, by the first NSM from the first NSE pod, the second attestation token, the second attestation token being based at least in part on the second randomly generated nonce. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod).
Nainar does not explicitly disclose the establishing token is a certification token. HASHMI, in analogous art however, discloses the establishing token is a certification token ([0098] At Step 3, the sidecar 514 may be implemented to use the application identity token 522 to broker an identity token with enterprise scope 524. In an exemplary embodiment, the pod 510 is provided with a platform internal token 516. In an exemplary embodiment, the platform internal token 516 is a JWT. In another exemplary embodiment, the platform internal identity token 516 is in the form of at least one X.509 certificate. The platform internal token 516 is a signed token which identifies the bearer to a party which trusts the issuer. The platform internal token 516 may be directly or indirectly connected to an API Server 518. A keys API 520 may be provided with the platform internal token 516. The keys API 520 may include or be related to a chain of trust. [0099] In Step 4A, application tokens database 506 may receive or accept an application identity token 522 from Identity Helper Sidecar 514. In an exemplary embodiment, the application identity token 522 is a JWT. In Step 4B, application tokens database 506 may communicate information to Keys API 520. Application tokens database may have a cache which may include a Keys API URL for every cluster. The Keys API URL may be Secure Socket Layer (SSL) enabled with a certificate in the chain of trust. In Step 4C, application tokens database 506 may transmit an identity token with enterprise scope 524 to the Identity Helper Sidecar 514. A micro-service may be created to expose the public key that was used to sign the application identity token 522. Application tokens database 506 may have a certificate in a chain of trust. An SSL connection may be used in Steps 4A through 4C. The SSL connection that may be used in Steps 4A through 4C may use a certificate in the chain of trust. In Step 5, information may be determined by the Identity Helper Sidecar 514. The information determined by the Identity Helper Sidecar 514 may be used by Pod 510. [0100] Referring to FIG. 6, a second data flow diagram 600 is shown. According to an exemplary embodiment, Steps in validating an application identity token 522 are presented. A cluster 502 may include a certificate service 608, an application identity token 522, and an identity token with enterprise scope 524. The cluster 502 may be a Kubernetes cluster or any platform which supports a running instance of an application. The cluster 502 may be configured to communicate with application tokens database 506. Application tokens database 506 may be configured to communicate with application-specific data repository 504. The cluster 502 may create an entry in application-specific data repository 504 for the application identification and cluster combination. Application tokens database 506 may verify the application component and cluster combination before returning the identity token with enterprise scope 524).
HASHMI further discloses ([0104-0105] Referring to FIG. 7, a third data flow diagram 700 is shown. According to an exemplary embodiment, a cluster 502 (e.g., Kubemetes cluster or any platform which supports a running instance of an application) may be in communication with application-specific data repository 504. In an exemplary embodiment, the cluster 502 publishes a public key endpoint URL to application-specific data repository 504. The cluster 502 may include a cluster Certificate Authority (CA) 704 that is configured to issue a plurality of certificates, including, but not limited to, a controller-manager certificate 706, an API-server certificate 708, and a service-account certificate 710. There may be relevant API Server Parameters. For example, relevant API Server Parameters may include, but are not limited to, a service account key file, a service account signing key file, a service account issuer, and a service account API audience. The service account key file may relate to a private key used to sign a service account application identity token. The service account signing key file may relate to a public key used to sign a service account application identity token. The service account issuer may relate to an issuer attribute in the certificate used to sign the application identity token. The service account API audience may relate to at least one service account token that may be transmitted via a projected volume method. The at least one service account token may have a tag with a specified audience value). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations disclosed by Nainar to include the establishing token is a certification token. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to facilitate an identification of an application that runs on a platform by establishing the identity of the applications that run on the platform and making the identity available, for example, to application containers, nodes, workers, minions, or machines where workloads are deployed such that the applications can seamlessly connect to other services without the need for authentication such as passwords as suggested by HASHMI ([0005]).
As per claim 12: Nainar discloses a certification server capable of establishing a token of an instantiation of a node cluster comprising ([0016] In configurations, an attestation token may allow for providing a unidirectional integrity check within a cluster of nodes, or between nodes of different clusters)
a master node and at least one compute node ([0024] a portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform. The portion 102 includes a master node 104 and two worker nodes 106a, 106b. As is known, the portion 102 may include many more worker nodes 106. The master node 104 includes an API-server 108 a. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108) comprising
at least one container intended to execute at least one task ([0006] FIGS. 1A, 1B, and 1C a portion of a container-orchestration system configured in accordance with the Kubernetes platform), said certification server comprising
at least one processor configured to: transmit a first set of certification parameters to said master node ([0013] When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server);
transmit at least one second set of certification parameters to at least one container of said compute node ([0021] The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token);
receive, from said master node, a request for generating said token of an instantiation of the node cluster ([0019] The local NSM receiving the request for an integrity verified path from the requesting pod may request the attestation token from the NSE pod. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod. When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server),
said request comprising
a first instantiation certificate of said master node established by means of the first set of certification parameters ([0024] The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114) and
at least one second instantiation certificate of said container established by means of the second set of certification parameters ([0026]The request may include a second locally generated nonce generated by the NSM 110a. The NSE pod 114 may generate the second attestation token using the second nonce and provide the second attestation token to the NSM 110a. The NSM 110a may have the attestation token verified by the CA server 120, thereby confirming the integrity of the NSE pod 114. Since the attestation tokens verify the integrity of the pods 112, 114, the NSM 110a may instantiate the integrity verified path 116 between the pod 112 and the NSE pod 114 and inject the integrity verified path 116 into the pod 112);
generate said token of an instantiation of the node cluster by means of said first certificate and said at least one second certificate ([0013] generating, by the first pod, the first attestation token, receiving, by the first NSM from the first pod, the first attestation token, and verifying, by the first NSM, the first attestation token with a certificate authority (CA) server. The method may additionally include providing, by the first NSM to the first NSE pod, a third request for a second attestation token, the third request including a second randomly generated nonce and receiving, by the first NSM from the first NSE pod, the second attestation token, the second attestation token being based at least in part on the second randomly generated nonce. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod); and
transmit said token of an instantiation of the node cluster to said master node ([0013] When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server).
Nainar does not explicitly disclose the establishing token is a certification token. HASHMI, in analogous art however, discloses the establishing token is a certification token ([0098] At Step 3, the sidecar 514 may be implemented to use the application identity token 522 to broker an identity token with enterprise scope 524. In an exemplary embodiment, the pod 510 is provided with a platform internal token 516. In an exemplary embodiment, the platform internal token 516 is a JWT. In another exemplary embodiment, the platform internal identity token 516 is in the form of at least one X.509 certificate. The platform internal token 516 is a signed token which identifies the bearer to a party which trusts the issuer. The platform internal token 516 may be directly or indirectly connected to an API Server 518. A keys API 520 may be provided with the platform internal token 516. The keys API 520 may include or be related to a chain of trust. [0099] In Step 4A, application tokens database 506 may receive or accept an application identity token 522 from Identity Helper Sidecar 514. In an exemplary embodiment, the application identity token 522 is a JWT. In Step 4B, application tokens database 506 may communicate information to Keys API 520. Application tokens database may have a cache which may include a Keys API URL for every cluster. The Keys API URL may be Secure Socket Layer (SSL) enabled with a certificate in the chain of trust. In Step 4C, application tokens database 506 may transmit an identity token with enterprise scope 524 to the Identity Helper Sidecar 514. A micro-service may be created to expose the public key that was used to sign the application identity token 522. Application tokens database 506 may have a certificate in a chain of trust. An SSL connection may be used in Steps 4A through 4C. The SSL connection that may be used in Steps 4A through 4C may use a certificate in the chain of trust. In Step 5, information may be determined by the Identity Helper Sidecar 514. The information determined by the Identity Helper Sidecar 514 may be used by Pod 510. [0100] Referring to FIG. 6, a second data flow diagram 600 is shown. According to an exemplary embodiment, Steps in validating an application identity token 522 are presented. A cluster 502 may include a certificate service 608, an application identity token 522, and an identity token with enterprise scope 524. The cluster 502 may be a Kubernetes cluster or any platform which supports a running instance of an application. The cluster 502 may be configured to communicate with application tokens database 506. Application tokens database 506 may be configured to communicate with application-specific data repository 504. The cluster 502 may create an entry in application-specific data repository 504 for the application identification and cluster combination. Application tokens database 506 may verify the application component and cluster combination before returning the identity token with enterprise scope 524.
HASHMI further discloses ([0104-0105] Referring to FIG. 7, a third data flow diagram 700 is shown. According to an exemplary embodiment, a cluster 502 (e.g., Kubemetes cluster or any platform which supports a running instance of an application) may be in communication with application-specific data repository 504. In an exemplary embodiment, the cluster 502 publishes a public key endpoint URL to application-specific data repository 504. The cluster 502 may include a cluster Certificate Authority (CA) 704 that is configured to issue a plurality of certificates, including, but not limited to, a controller-manager certificate 706, an API-server certificate 708, and a service-account certificate 710. There may be relevant API Server Parameters. For example, relevant API Server Parameters may include, but are not limited to, a service account key file, a service account signing key file, a service account issuer, and a service account API audience. The service account key file may relate to a private key used to sign a service account application identity token. The service account signing key file may relate to a public key used to sign a service account application identity token. The service account issuer may relate to an issuer attribute in the certificate used to sign the application identity token. The service account API audience may relate to at least one service account token that may be transmitted via a projected volume method. The at least one service account token may have a tag with a specified audience value). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations disclosed by Nainar to include the establishing token is a certification token. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to facilitate an identification of an application that runs on a platform by establishing the identity of the applications that run on the platform and making the identity available, for example, to application containers, nodes, workers, minions, or machines where workloads are deployed such that the applications can seamlessly connect to other services without the need for authentication such as passwords as suggested by HASHMI ([0005]).
As per claim 14: Nainar discloses an item of equipment to access a service implemented by a node cluster comprising ([0016] In configurations, an attestation token may allow for providing a unidirectional integrity check within a cluster of nodes, or between nodes of different clusters) a master node and at least one compute node([0024] a portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform. The portion 102 includes a master node 104 and two worker nodes 106a, 106b. As is known, the portion 102 may include many more worker nodes 106. The master node 104 includes an API-server 108 a. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108) comprising
at least one container intended to execute at least one task ([0006] FIGS. 1A, 1B, and 1C a portion of a container-orchestration system configured in accordance with the Kubernetes platform), said item of equipment comprising
at least one processor configured to: transmit, to said master node, a request for establishing a session with said node cluster ([0019] The local NSM receiving the request for an integrity verified path from the requesting pod may request the attestation token from the NSE pod. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod. When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server);
receive a signalling message relating to the establishment of said session ([0025] The request for the integrity verified path 116 that is sent to the NSM 110a may include various attributes. For example, the request may include attributes such as, for example, a label (e.g., conditions for selecting a NSE for providing a desired service), a network service (e.g., the type of desired service), and a color (e.g., quality of service). In configurations, the request may also include integrity attributes including integrity-verified (an indication if the node that includes the NSE pod should be integrity verified) and continuous (an indication if the node that includes the NSE pod needs to only initially be integrity verified or if the node should be periodically re-validated for integrity, e.g., the node should be continuously integrity verified) further comprising
said token established by a certification server by means of a first instantiation certificate of said master node established by means of a first set of certification parameters requested from the certification server ([0024] The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114); and
at least one second instantiation certificate of said container established by means of a second set of certification parameters requested from the certification server ([0026]The request may include a second locally generated nonce generated by the NSM 110a. The NSE pod 114 may generate the second attestation token using the second nonce and provide the second attestation token to the NSM 110a. The NSM 110a may have the attestation token verified by the CA server 120, thereby confirming the integrity of the NSE pod 114. Since the attestation tokens verify the integrity of the pods 112, 114, the NSM 110a may instantiate the integrity verified path 116 between the pod 112 and the NSE pod 114 and inject the integrity verified path 116 into the pod 112); and
verify the authenticity of said token with said certification server ([0013] generating, by the first pod, the first attestation token, receiving, by the first NSM from the first pod, the first attestation token, and verifying, by the first NSM, the first attestation token with a certificate authority (CA) server. The method may additionally include providing, by the first NSM to the first NSE pod, a third request for a second attestation token, the third request including a second randomly generated nonce and receiving, by the first NSM from the first NSE pod, the second attestation token, the second attestation token being based at least in part on the second randomly generated nonce. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod).
Nainar does not explicitly disclose the establishing token is a certification token. HASHMI, in analogous art however, discloses the establishing token is a certification token ([0098] At Step 3, the sidecar 514 may be implemented to use the application identity token 522 to broker an identity token with enterprise scope 524. In an exemplary embodiment, the pod 510 is provided with a platform internal token 516. In an exemplary embodiment, the platform internal token 516 is a JWT. In another exemplary embodiment, the platform internal identity token 516 is in the form of at least one X.509 certificate. The platform internal token 516 is a signed token which identifies the bearer to a party which trusts the issuer. The platform internal token 516 may be directly or indirectly connected to an API Server 518. A keys API 520 may be provided with the platform internal token 516. The keys API 520 may include or be related to a chain of trust. [0099] In Step 4A, application tokens database 506 may receive or accept an application identity token 522 from Identity Helper Sidecar 514. In an exemplary embodiment, the application identity token 522 is a JWT. In Step 4B, application tokens database 506 may communicate information to Keys API 520. Application tokens database may have a cache which may include a Keys API URL for every cluster. The Keys API URL may be Secure Socket Layer (SSL) enabled with a certificate in the chain of trust. In Step 4C, application tokens database 506 may transmit an identity token with enterprise scope 524 to the Identity Helper Sidecar 514. A micro-service may be created to expose the public key that was used to sign the application identity token 522. Application tokens database 506 may have a certificate in a chain of trust. An SSL connection may be used in Steps 4A through 4C. The SSL connection that may be used in Steps 4A through 4C may use a certificate in the chain of trust. In Step 5, information may be determined by the Identity Helper Sidecar 514. The information determined by the Identity Helper Sidecar 514 may be used by Pod 510. [0100] Referring to FIG. 6, a second data flow diagram 600 is shown. According to an exemplary embodiment, Steps in validating an application identity token 522 are presented. A cluster 502 may include a certificate service 608, an application identity token 522, and an identity token with enterprise scope 524. The cluster 502 may be a Kubernetes cluster or any platform which supports a running instance of an application. The cluster 502 may be configured to communicate with application tokens database 506. Application tokens database 506 may be configured to communicate with application-specific data repository 504. The cluster 502 may create an entry in application-specific data repository 504 for the application identification and cluster combination. Application tokens database 506 may verify the application component and cluster combination before returning the identity token with enterprise scope 524).
HASHMI further discloses ([0104-0105] Referring to FIG. 7, a third data flow diagram 700 is shown. According to an exemplary embodiment, a cluster 502 (e.g., Kubemetes cluster or any platform which supports a running instance of an application) may be in communication with application-specific data repository 504. In an exemplary embodiment, the cluster 502 publishes a public key endpoint URL to application-specific data repository 504. The cluster 502 may include a cluster Certificate Authority (CA) 704 that is configured to issue a plurality of certificates, including, but not limited to, a controller-manager certificate 706, an API-server certificate 708, and a service-account certificate 710. There may be relevant API Server Parameters. For example, relevant API Server Parameters may include, but are not limited to, a service account key file, a service account signing key file, a service account issuer, and a service account API audience. The service account key file may relate to a private key used to sign a service account application identity token. The service account signing key file may relate to a public key used to sign a service account application identity token. The service account issuer may relate to an issuer attribute in the certificate used to sign the application identity token. The service account API audience may relate to at least one service account token that may be transmitted via a projected volume method. The at least one service account token may have a tag with a specified audience value). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations disclosed by Nainar to include the establishing token is a certification token. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to facilitate an identification of an application that runs on a platform by establishing the identity of the applications that run on the platform and making the identity available, for example, to application containers, nodes, workers, minions, or machines where workloads are deployed such that the applications can seamlessly connect to other services without the need for authentication such as passwords as suggested by HASHMI ([0005]).
BRI (Broadest Reasonable Interpretation) Considerations
The above claims under examination have been given to them their BRI considerations consistent with the applicant’s disclosure as they would be interpreted by ordinary skill in the art (POSITA) at the time of filing of the invention. In order to construe, appraise boundary and scope of the claimed limitations, the following claim words or terms or phrases or languages have been given to them their BRI considerations and context in view of the applicant’s disclosure. For record clarity, BRI for the following claim words or terms or phrases or languages, the examiner recites descriptions from the applicant’s disclosure as follows:
Node Cluster, Master node, compute node and Containers: [Applicant’s Disclosure: 0007-0009] FIG. 1 shows in a simplified manner the architecture of a node cluster 1 compliant with the Kubernetes architecture. The node cluster 1 comprises a first node 10 referred to as master node, or “Kubernetes master”, and N compute nodes, or “workers nodes”, 11i, i∈{1, . . . , N}, N being a natural integer. The master node 10 comprises a controller 101, an API (Application Programming Interface) module 102 and an ETCD database 103 that consists of a dynamic configuration register for the compute nodes 11i. A compute node 11i comprises M containers or “pods” 110j, j∈{1, . . . , M}, M being a natural integer. Each container 110j is equipped with resources for executing one or more tasks. When a task is executed, it contributes to implementing a network service or a function, such as a DHCP (Dynamic Host Configuration Protocol) function, for example.
[0119-0120] Such a system comprises at least one node cluster 1 compliant with the Kubernetes architecture. The node cluster 1 comprises a first node 10 referred to as master node and N compute nodes 11i, i∈{1, . . . , N}, N being a natural integer. A compute node 11i comprises M containers or “pods” 110j, j∈{1, . . . , M}, M being a natural integer. Each container 110j is equipped with resources for executing one or more tasks. When a task is executed, it contributes to implementing a network service or a function, such as a DHCP (Dynamic Host Configuration Protocol) function, for example.
Conclusion
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure. See the notice of reference cited in form PTO-892 for additional prior arts.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, LINGLAN EDWARDS can be reached at (571) 270-5440. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/TECHANE GERGISO/Primary Examiner, Art Unit 2408