Kubernetes relies heavily on Public Key Infrastructure (PKI) to secure communication between cluster components. In the context of the CKA exam, understanding how these certificates are generated, managed, and rotated is crucial for maintaining cluster health and security. The cluster utilizes a Ro…Kubernetes relies heavily on Public Key Infrastructure (PKI) to secure communication between cluster components. In the context of the CKA exam, understanding how these certificates are generated, managed, and rotated is crucial for maintaining cluster health and security. The cluster utilizes a Root Certificate Authority (CA) to sign certificates for core components like the API Server, etcd, Kubelet, Scheduler, and Controller Manager.
When using tools like `kubeadm`, these certificates are generated automatically, typically with a one-year validity. To prevent cluster failure, these certificates must be rotated before they expire. Administrators can verify validity using `kubeadm certs check-expiration` or OpenSSL commands. Certificate rotation involves generating new certificates and restarting control plane processes to reload them. While `kubeadm` offers the `kubeadm certs renew` command to automate the generation of new files in `/etc/kubernetes/pki`, the administrator must ensure static pods are restarted to apply changes.
For worker nodes, Kubernetes supports automatic Kubelet certificate rotation. By enabling specific Kubelet configuration flags and the `NodeRestriction` admission controller, Kubelets can request new certificates via the API Server as they approach expiration. These requests generate Certificate Signing Request (CSR) objects. The Kube-Controller-Manager can be configured to automatically approve these requests, or an administrator may need to manually intervene using `kubectl certificate approve` and `kubectl certificate deny`. Mastery of the CSR API is essential for managing user access and node TLS bootstrapping.
Certificate Management and Rotation
Why it is Important Kubernetes relies fundamentally on Public Key Infrastructure (PKI) for security. Almost every interaction within the cluster—between the API server, etcd, the Kubelet, the Scheduler, and the Controller Manager—happens over TLS (Transport Layer Security). If certificates expire, components fail to authenticate, causing the cluster to stop functioning. Furthermore, regular certificate rotation is a critical security best practice to limit the lifespan of cryptographic keys, reducing the impact if a key is ever compromised.
What it is Certificate Management involves the creation, distribution, and maintenance of X.509 certificates for the various Kubernetes components. There are two primary types of authorities usually found in a cluster: 1. Cluster CA: Signs certificates for the API server and clients. 2. Etcd CA: Specifically for the etcd cluster (often separate for security).
Rotation is the process of renewing these certificates before they reach their expiration date (typically 1 year for kubeadm-managed clusters) or regenerating them if a breach is suspected.
How it works In a standard environment (like one created with kubeadm), certificates are stored in /etc/kubernetes/pki/. The kube-apiserver acts as the central hub and requires the most certificates (to talk to etcd, to talk to kubelets, and to verify incoming connections).
The Certificate Signing Request (CSR) API: Kubernetes has a built-in API allows automation of certificate management. A client (like a Kubelet or a user) creates a private key and sends a CSR object to the API server. An administrator (or a controller) approves this CSR, and the Controller Manager signs it using the Cluster CA, generating a valid certificate for the client.
How to Answer Questions on Certificate Management In the CKA exam, you will likely face three types of scenarios:
1. Checking Expiration: You may need to identify an expired certificate. Use the command: kubeadm certs check-expiration Alternatively, you can inspect a specific file using OpenSSL: openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout
2. Renewing Certificates: If asked to renew certificates on a control plane node managed by kubeadm: kubeadm certs renew all After renewal, you must restart the control plane components (static pods) by temporarily moving the manifest files out of /etc/kubernetes/manifests/ and moving them back in, or by restarting the kubelet.
3. Managing CSRs (Manual Rotation/User Onboarding): You may be asked to generate a certificate for a user or approve a pending node CSR. Step A: Create a CertificateSigningRequest YAML object. Ensure the 'request' field is the base64 encoded CSR generated by OpenSSL. Step B: Apply the YAML: kubectl apply -f csr.yaml Step C: Approve the CSR: kubectl certificate approve [name] Step D: Retrieve the certificate: kubectl get csr [name] -o jsonpath='{.status.certificate}' | base64 --decode > user.crt
Exam Tips: Answering Questions on Certificate management and rotation • Know your paths: Memorize /etc/kubernetes/pki (Control plane certs) and /var/lib/kubelet/pki (Kubelet certs). • Permissions matter: When creating a CSR YAML, ensure `usages` include client auth if creating a user certificate, or server auth for a backend service. • Don't panic on 'Connection Refused': If the API server is down due to bad certs, you cannot use kubectl. You must use docker ps or crictl ps to check container logs, and use filesystem commands (like openssl) to debug. • Kubeadm is your friend: Unless the question specifically forbids it or asks for a manual OpenSSL approach (which is rare for core component renewal), use kubeadm certs renew to save time. • Base64 Decoding: Remember that data in a CSR YAML must be base64 encoded on one line. When extracting the signed certificate, do not forget to decode it.