End-to-End Kubernetes with Rancher, RKE2, K3s, Fleet, Longhorn, and NeuVector

Certificate Rotation

By default, Kubernetes clusters rely on certificates to establish secure communication between their various components, such as the etcd, kube-apiserver, kube-controller-manager, kube-scheduler, and kubelet. These certificates serve as the foundational security mechanism for the cluster. They are used to ensure that the cluster maintains confidentiality, integrity, and authentication across its internal communications. Since they are so critical to the cluster's security, it is important to ensure that they are regularly rotated.

In Rancher-launched Kubernetes clusters, the process of rotating certificates can be easily managed through the Rancher UI. This process involves creating a new certificate and key pair, updating the cluster components to use the new certificate, and then restarting the components to apply the changes (if necessary).

In RKE2 clusters, the following certificates are typically rotated:

• admin
• api-server
• controller-manager
• scheduler
• rke2-controller
• rke2-server
• cloud-controller
• etcd
• auth-proxy
• kubelet
• kube-proxy