Skip to main content
This article explains how to manage certificates and introduces the Certificate API in Kubernetes. In a typical cluster setup, an administrator first configures a Certificate Authority (CA) server and generates certificates for the various components. Once the services are launched with these certificates, the cluster becomes operational. Initially, only one administrator has access via a personal admin certificate and key. However, as new team members join, each must obtain their own certificate and key pair to access the cluster.

​
The Certificate Lifecycle

When a new administrator joins, she generates her own private key and creates a certificate signing request (CSR). This CSR is then sent to the existing administrator. As the sole administrator, you review the CSR, sign it using the CA server’s private key and root certificate, and return the signed certificate. The new admin now has a valid certificate and key pair to access the cluster. Since certificates have a defined expiration period, the process is repeated when they expire. The Kubernetes API Server plays a pivotal role in the cluster but is not part of the Certificate Authority. The CA is comprised of only two files—a key and a certificate—generated during initialization. Because these files allow the signing of certificates and thus the creation of users with any privileges, they must be stored securely, typically on a dedicated CA server. In many implementations, the Kubernetes master node also serves as the CA server. For instance, the kubeadm tool creates and stores CA files on the master node.
As the number of users increases, manually signing certificate requests becomes impractical. Kubernetes addresses this challenge with a built-in Certificates API that automates CSR management and certificate rotation.

​
Managing Certificate Signing Requests (CSRs)

The Kubernetes Certificates API allows users to submit their CSRs via an API call, creating a CertificateSigningRequest object. Administrators can then review and approve these requests using kubectl commands. Once approved, Kubernetes signs the certificate using the CA’s key pair. The signed certificate is then available for extraction and distribution to the requesting user.
The image illustrates a process involving creating, reviewing, and approving CertificateSigningRequest objects using a Certificates API, with icons representing users and servers.

​
Step 1: User Generates Private Key and CSR

A user creates a private key and generates a certificate signing request using the following command:
The user then sends the CSR to the administrator.

​
Step 2: Administrator Creates a CSR Object

The administrator creates a CertificateSigningRequest object with a manifest file. In the manifest, the kind is set to CertificateSigningRequest, and the spec section includes the encoded certificate signing request (CSR must be encoded in base64). Below is an example manifest:
Administrators can list pending CSRs with the following command:
The output may resemble:

​
Step 3: Approving the CSR

To approve the CSR, run:
After approval, Kubernetes signs the CSR with the CA key pair, and the certificate is embedded in the CertificateSigningRequest object’s YAML output as a base64 encoded string. You can decode it using base64 utilities to view the plain text certificate. Below is an example output of a CertificateSigningRequest object:

​
The Role of the Controller Manager

Within the Kubernetes control plane, components such as the API Server, Scheduler, and Controller Manager work together. However, all certificate-related operations—such as CSR approval and signing—are managed by the Controller Manager.
The image depicts a diagram of a Kubernetes architecture component, showing the Kube-API Server, Scheduler, and Controller Manager within a bordered rectangle.
The image shows a diagram labeled "Controller Manager" with two buttons: "CSR-APPROVING" and "CSR-SIGNING."
The Controller Manager includes dedicated controllers for CSR approval and CSR signing tasks. Since signing certificates requires access to the CA’s root certificate and private key, its configuration specifies the file paths to these credentials. For example, the Controller Manager’s configuration file might include settings like the following:
This configuration demonstrates how the Controller Manager accesses the necessary CA certificates for signing new certificate requests.

​
Conclusion

In summary, Kubernetes simplifies certificate management through its built-in Certificates API, automating the CSR lifecycle and certificate rotation. This automation is essential for maintaining secure access as team sizes grow and certificates expire over time. For further exploration, head over to the practice desk to experiment with the Certificates API and enhance your Kubernetes operations. See you in the next article!

Watch Video

Practice Lab