Skip to main content
This guide demonstrates how to generate certificates for a Kubernetes cluster using OpenSSL. While various tools such as EasyRSA and CFSSL can perform these tasks, our focus here is on OpenSSL for its simplicity and ease of use.

​
Creating the CA Certificate

First, create the Certificate Authority (CA) that will sign all other certificates. Follow these steps:
  1. Generate the private key for the CA:
  2. Create a certificate signing request (CSR) using the generated key. In this example, the common name (CN) is set to “KUBERNETES-CA”:
  3. Sign the CSR with the CA’s private key to create the CA certificate:
After these steps, the CA is ready with its private key and root certificate (ca.crt), which will be used to sign all other certificates in the cluster.

​
Generating Client Certificates

​
Admin User Certificate

To set up a certificate for the admin user:
  1. Generate a private key:
  2. Create a CSR for the admin user. Although the common name (CN) is “kube-admin”, you can choose a different name as needed:
  3. Sign the admin CSR using the CA’s certificate and key:
This certificate allows the admin user to authenticate with the Kubernetes API Server. For enhanced security and administrative privileges, include group details by specifying an Organizational Unit (OU) parameter. For example:

​
Other Client Certificates

The same procedure applies to other components within Kubernetes (e.g., Kube Scheduler, Controller Manager, and Kube Proxy). These system components typically have names prefixed with “system-” and follow the same signing process using the CA credentials.

​
Using Certificates for Cluster Communication

Once you generate the certificates, you can use them in multiple ways. To make a REST API call to the Kubernetes API Server with the admin certificate, you can run:
Alternatively, consolidate these parameters into a kubeconfig file that specifies the API server endpoint and certificate details:

​
Generating Server-Side Certificates

For mutual TLS authentication in Kubernetes, both the client and the server require a copy of the CA’s public certificate. This certificate is essential for verifying the authenticity of certificates presented by clients and servers.

​
etcd Server Certificate

To secure the etcd server, generate a certificate (e.g., “etcd-server”) and, if using a cluster, also generate peer certificates. These generated certificates are then referenced in the etcd server startup options. For example:
In this configuration, the CA certificate is used to validate any connecting clients.

​
Kube API Server Certificate

The Kube API Server requires a certificate to manage multiple alternate names such as:
  • kubernetes
  • kubernetes.default
  • kubernetes.default.svc
  • kubernetes.default.svc.cluster.local
  • Its IP address (e.g., the host or pod IP)
To create this certificate:
  1. Generate a key and CSR for the API Server:
  2. Create an OpenSSL configuration file (e.g., openssl.cnf) with alternate names:
  3. Sign the CSR using the CA credentials:
After generating the API Server certificate, include its location along with the client certificates when configuring the kube-apiserver. For example:
Each Kubernetes component uses the CA certificate to verify its clients, ensuring a completely secure communication channel.

​
Kubelet Certificates

The Kubelet, the node-level component responsible for managing pods, needs its own key and certificate pair. Moreover, when communicating with the API Server, the certificates should follow a naming convention such as “system:node<nodeName>.” This identification is used by the API Server to assign node-specific permissions. After generating these certificates, include them in the kubeconfig files for the respective nodes.
The image illustrates Kubernetes client certificates for nodes node01, node02, and node03, showing their authentication setup with kubelet servers using certificates and keys.

​
Summary

In this guide, we covered the process of generating TLS certificates for both clients and servers within a Kubernetes cluster. We began with the CA certificates, moved on to creating client certificates for admin users and system components, and finally addressed server-side certificates for etcd and the Kube API Server. Key points included:
  • Signing certificate requests using the CA credentials.
  • Configuring alternate names for API Server certificates.
  • Ensuring mutual TLS for secure communication.
In our next article, we will explore how to view certificate details and how tools like kubeadm handle certificate configuration.
The image illustrates the process of generating and signing a certificate for "Kube Scheduler," including key generation, certificate signing request, and certificate signing.
The image illustrates a certificate management system for Kubernetes, showing client and server certificates with keys for various components like admin, scheduler, and kubelet.

Watch Video