CertGrid CertGrid
Hands-on Lab·Kubernetes and Cloud Native Security Associate

Cluster PKI and Certificate Signing Requests

Every component of this cluster proves who it is with a certificate, and all of them trace back to files in one directory. This guide counts the authorities, reads the expiry dates, and then uses the CSR API to have the cluster CA issue a brand new identity.

Platform Security Guide 35 of 42 Advanced

kubeadm creates three CAs and issues leaf certificates valid for one year. There is no revocation in the apiserver - a certificate is valid until it expires.

The cka5001 cluster: one control plane and 3 schedulable workers, on Cilium.
Server NameIP AddressOSRolesCPURAMHDD
CKA5001192.168.0.41Ubuntu 26.04 LTSControl Plane Node (tainted NoSchedule)2 Core4 GB50 GB
CKA5001-NODE01192.168.0.42Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB
CKA5001-NODE02192.168.0.43Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB
CKA5001-NODE03192.168.0.44Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB

This guide includes

Use this when you have to explain how components prove who they are. This matters because a kubeadm cluster has more than one certificate authority, all of them sitting on one machine's disk - and the same CA will mint you a user identity if you ask it correctly.

Before you start

  1. How many certificate authorities this cluster has

  2. What the cluster CA is, and how long it lasts

  3. What the apiserver certificate says about itself

  4. The expiry dates, in one command

  5. Asking the cluster CA for an identity

  6. Approving it, and reading what came back

Official sources

← All KCSA guides