US-12621287-B2 - Trusted and secured client-server model in Kubernetes cluster pods

US12621287B2US 12621287 B2US12621287 B2US 12621287B2US-12621287-B2

Abstract

Systems and methods are provided for enabling a trusted and secured client-server model in a container orchestration environment. Various embodiments provide a trusted and secured client-server model leverages the concept of self-signed TLS certificates to automate and efficiently manage TLS connections. In some embodiments a Kubernetes API server injects a service token into each pod in a cluster. The Kubernetes API server also injects the certificate used to generate the service token. In a client server model between pods, clients can use the same service token as its identity to the server and the server can use the same certificate for validating the token. In this way, trust is established using token-based authentication between clients and servers.

Inventors

Dhatchana Moorthy Sekar

Assignees

OPEN TEXT INC.

Dates

Publication Date: 20260505
Application Date: 20240522

Claims (17)

1 . A method of securing communications between Kubernetes pods in a Kubernetes container orchestration platform cluster, comprising: pushing, by a Kubernetes container orchestration platform application programming interface (API) server, service tokens and certificates to a Kubernetes client pod and to a Kubernetes server pod; generating, by the Kubernetes server pod, a self-signed certificate; pushing, by the Kubernetes server pod, the self-signed certificate into a shared memory; pulling, by the Kubernetes client pod, the self-signed certificate from the shared memory; and establishing a secure transport layer security (TLS) connection between the Kubernetes client pod and the Kubernetes server pod using the self-signed certificate and the service token of the Kubernetes client pod.
2 . The method of claim 1 , wherein the shared memory comprises a persistent volume claim (PVC).
3 . The method of claim 1 , wherein the service tokens are JSON web tokens (JWT).
4 . The method of claim 1 , wherein the self-signed certificate includes a public key associated with the Kubernetes server pod.
5 . The method of claim 1 , further comprising: wherein a service token is also pushed to a second Kubernetes client pod; pulling, by the second Kubernetes client pod, the self-signed certificate from the shared memory; and establishing a second secure transport layer security (TLS) connection between the second Kubernetes client pod and the Kubernetes server pod using the self-signed certificate and the service token of the second Kubernetes client pod.
6 . The method of claim 1 , wherein the service tokens and certificates are also pushed to a second Kubernetes server pod, the method further comprising: generating, by the second Kubernetes server pod, a second self-signed certificate; pushing, by the second Kubernetes server pod, the second self-signed certificate into shared memory; responsive to a detected failure of the Kubernetes client pod: pulling, by the Kubernetes client pod, the second self-signed certificate from the shared memory; and establishing a second secure transport layer security (TLS) connection between the Kubernetes client pod and the second Kubernetes server pod using the second self-signed certificate and the service token of the Kubernetes client pod.
7 . A system for securing communications between Kubernetes pods in a Kubernetes container orchestration platform cluster, comprising: a processor; a non-transitory computer-readable medium storing instructions that, when executed by the processor, cause the processor to perform operations including: pushing, by a Kubernetes container orchestration platform application programming interface (API) server, service tokens and certificates to a Kubernetes client pod and to a Kubernetes server pod; generating, by the Kubernetes server pod, a self-signed certificate; pushing, by the Kubernetes server pod, the self-signed certificate into a shared memory; pulling, by the Kubernetes client pod, the self-signed certificate from the shared memory; and establishing a secure transport layer security (TLS) connection between the Kubernetes client pod and the Kubernetes server pod using the self-signed certificate and the service token of the Kubernetes client pod.
8 . The system of claim 7 , wherein the shared memory comprises a persistent volume claim (PVC).
9 . The system of claim 7 , wherein the service tokens are JSON web tokens (JWT).
10 . The system of claim 7 , wherein the self-signed certificate includes a public key associated with the Kubernetes server pod.
11 . The system of claim 7 , wherein the instructions further comprise: wherein a service token is also pushed to a second Kubernetes client pod; pulling, by the second Kubernetes client pod, the self-signed certificate from the shared memory; and establishing a second secure transport layer security (TLS) connection between the second Kubernetes client pod and the Kubernetes server pod using the self-signed certificate and the service token of the second Kubernetes client pod.
12 . The system of claim 7 , wherein the service tokens and certificates are also pushed to a second Kubernetes server pod, wherein the instructions further comprise: generating, by the second Kubernetes server pod, a second self-signed certificate; pushing, by the second Kubernetes server pod, the second self-signed certificate into shared memory; responsive to a detected failure of the Kubernetes client pod: pulling, by the Kubernetes client pod, the second self-signed certificate from the shared memory; and establishing a second secure transport layer security (TLS) connection between the Kubernetes client pod and the second Kubernetes server pod using the second self-signed certificate and the service token of the Kubernetes client pod.
13 . A computer programming product comprising a non-transitory computer-readable medium storing instructions for securing communications between Kubernetes pods in a Kubernetes container orchestration platform cluster, the stored instructions, when executed by a processor, cause the processor to perform operations including: pushing, by a Kubernetes container orchestration platform application programming interface (API) server, service tokens and certificates to a Kubernetes client pod and to a Kubernetes server pod; generating, by the Kubernetes server pod, a self-signed certificate; pushing, by the Kubernetes server pod, the self-signed certificate into a shared memory; pulling, by the Kubernetes client pod, the self-signed certificate from the shared memory; and establishing a secure transport layer security (TLS) connection between the Kubernetes client pod and the Kubernetes server pod using the self-signed certificate and the service token of the Kubernetes client pod.
14 . The computer programming product of claim 13 , wherein the shared memory comprises a persistent volume claim (PVC).
15 . The computer programming product of claim 13 , wherein the service tokens are JSON web tokens (JWT).
16 . The computer programming product of claim 13 , wherein the instructions further comprise: wherein a service token is also pushed to a second Kubernetes client pod; pulling, by the second Kubernetes client pod, the self-signed certificate from the shared memory; and establishing a second secure transport layer security (TLS) connection between the second Kubernetes client pod and the Kubernetes server pod using the self-signed certificate and the service token of the second Kubernetes client pod.
17 . The computer programming product of claim 13 , wherein the service tokens and certificates are also pushed to a second Kubernetes server pod, wherein the instructions further comprise: generating, by the second Kubernetes server pod, a second self-signed certificate; pushing, by the second Kubernetes server pod, the second self-signed certificate into shared memory; responsive to a detected failure of the Kubernetes client pod: pulling, by the Kubernetes client pod, the second self-signed certificate from the shared memory; and establishing a second secure transport layer security (TLS) connection between the Kubernetes client pod and the second Kubernetes server pod using the second self-signed certificate and the service token of the Kubernetes client pod.

Description

TECHNICAL FIELD This disclosure relates generally to the field of content management. In particular, this disclosure relates to systems, methods, and computer program products for providing a trusted and secured client-server model in a container orchestration cloud environment. BACKGROUND Containerization relates to an application-level virtualization over multiple network resources enabling software applications to run in isolated user spaces called containers in a cloud or non-cloud environment. In some examples, containers are basically fully functional and portable cloud or non-cloud computing environments surrounding an application and keeping the application independent from other parallel environments. In some uses, each container simulates a different software application and runs isolated processes by bundling related configuration files, libraries, and dependencies. Container deployment is the act of deploying containers to their target environment, such as a cloud or on-premises server. In a container orchestration cloud environment, such as Kubernetes (K8s), security is a multifaceted topic that requires attention to various aspects of cluster management, configuration, and application deployment. For example, security issues can arise from unauthenticated access to the application programming interface (API) server, insecure network policies, weak or misconfigured authentication mechanisms, insecure network configurations, etc. Kubernetes allows for the storage and management of sensitive information such as API tokens, database passwords, and transport layer security (TLS) certificates as secrets. However, mismanagement of secrets, such as storing them in plaintext or exposing them in other ways, can lead to security breaches. Using mechanisms for the management of secrets is crucial for secure secrets management. In view of the foregoing, there is room for innovations and improvements for providing customization, release management, and maintenance in a container orchestration environment. SUMMARY In some embodiments, systems and methods are described for securing communications between pods in a container orchestration platform cluster that push, by a container orchestration platform API server, service tokens and certificates to a client pod and to a server pod. One or more server pods generate a self-signed certificate and store the certificate in memory. The server pod also pushes the self-signed certificate into a shared memory, where it can be pulled by a client pod and used to establish a TLS connection between the client and the server pod. In some embodiments, multiple servers can be configured to be used with an HA failover system. Embodiments of the present invention also include computer-readable storage media containing sets of instructions to cause one or more processors to perform the methods, variations of the methods, and other operations described herein. These, and other, aspects of the disclosure will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following description, while indicating various embodiments of the disclosure and numerous specific details thereof, is given by way of illustration and not of limitation. Many substitutions, modifications, additions and/or rearrangements may be made within the scope of the disclosure without departing from the spirit thereof, and the disclosure includes all such substitutions, modifications, additions and/or rearrangements. BRIEF DESCRIPTION OF THE FIGURES The drawings accompanying and forming part of this specification are included to depict certain aspects of the invention. A clearer impression of the invention, and of the components and operation of systems provided with the invention, will become more readily apparent by referring to the exemplary, and therefore nonlimiting, embodiments illustrated in the drawings, wherein identical reference numerals designate the same components. Note that the features illustrated in the drawings are not necessarily drawn to scale. FIG. 1 is a block diagram of a Kubernetes cluster. FIG. 2 is a diagram illustrating a process for trust between client and server pods established through a service token. FIG. 3 is a diagram illustrating a process for trust between client and server pods established through a service token. FIG. 4 is a sequence diagram illustrating an exemplary set of steps used to establish a TLS connection between client pods and a server pod. FIG. 5 is a process diagram illustrating an example of a process for trust between client and server pods. FIG. 6 is a sequence diagram illustrating an exemplary set of steps used to establish a TLS connection between client pods and one or more server pods. FIG. 7A shows an example of pseudocode for a client curl call using a service token and certificate in PVC, as described above. FIG. 7B shows an example of