TLS in Kubernetes

Welcome to this in-depth lesson on securing your Kubernetes cluster with TLS certificates. In this guide, we'll explain the roles and naming conventions of various certificates, and then demonstrate how these concepts apply within a Kubernetes environment.

In a previous discussion, we explored the basics of public and private keys and their role in securing connections. The certificates we reviewed included:

• Server Certificates: Deployed on servers.
• Root Certificates: Held by the Certificate Authority (CA) to sign server certificates.
• Client Certificates: Used by clients to authenticate themselves to the server.

The image below illustrates the Certificate Authority (CA) system, showing the root, client, and server certificates along with their public and private keys:

TLS Components in a Kubernetes Cluster

A secure Kubernetes cluster requires encrypted TLS communications between the master and worker nodes. Whether you are an administrator using kubectl or an internal service within the cluster, every interaction relies on TLS-secured connections. There are two main requirements:

1. Server components (e.g., API server, etcd, kubelet) must use TLS certificates to secure communications.
2. Client components (e.g., administrative users, scheduler, controller-manager, kube-proxy) must present valid client certificates for authentication.

Server Certificates

Below we identify the key server components and their associated certificates:

• Kube API Server:
  The Kube API server provides an HTTPS service for internal components and external users. It requires a server certificate and a private key (api-server.cert and api-server.key) to secure these communications.

• etcd Server:
  Acting as the primary data store for the cluster, the etcd server necessitates its certificate and key pair, named etcd-server.crt and etcd-server.key.

• Kubelet (Worker Nodes):
  Every worker node runs the kubelet service, which exposes an HTTPS API endpoint for communication with the API server. For these endpoints, a certificate and key pair (kubelet.cert and kubelet.key) is used.

The diagram below summarizes the server certificates used by the Kube API, etcd, and kubelet services:

Client Certificates

Now, review the client components that interact with the servers:

• Admin User:
  Administrators connect to the Kubernetes cluster via kubectl or direct REST API calls. The admin user authenticates with a client certificate (admin.crt) and corresponding key (admin.key).

• Scheduler:
  The scheduler queries the API server for pending pods and orchestrates their deployment on the appropriate worker nodes. It uses a certificate and key pairing (scheduler.cert and scheduler.key) for authentication.

• Kube Controller Manager:
  Similar to the scheduler, the controller manager communicates with the API server using its own certificate for secure authentication.

• Kube Proxy:
  The kube proxy manages network rules on worker nodes and requires a dedicated client certificate (kube-proxy.crt and kube-proxy.key).

The diagram below provides an overview of how client certificates and keys are used for authentication among Kubernetes components:

Grouping Certificates

To simplify management, certificates in a Kubernetes cluster can be categorized into two groups:

The Role of the Certificate Authority (CA)

A Certificate Authority (CA) is needed to sign both client and server certificates. Kubernetes requires at least one CA per cluster. In some deployments, a separate CA may be used for the control plane and for etcd. In this lesson, we focus on a single CA whose certificate and key are named CA.crt and CA.key.

The following diagram offers a comprehensive overview of the client and server certificates for various Kubernetes components, all signed by the CA:

This concludes the overview of the TLS certificates used in a Kubernetes cluster along with their respective roles. In the next section of this lesson, we will explore how to generate and sign these certificates using the CA.