Skip to main content
In this lesson we cover how TLS certificates are used to secure a Kubernetes cluster. You will learn the roles of public/private keys, Certificate Authorities (CAs), and how server and client certificates map to Kubernetes components. Why this matters
  • TLS ensures confidentiality, integrity, and authentication for communication between cluster components and administrators.
  • Proper certificate management (creation, signing, rotation, storage) is fundamental for cluster security and availability.
Quick recap
  • Public/private key pairs are the foundation of TLS. A server keeps a private key and presents a certificate (containing the public key) so clients can verify its identity.
  • A Certificate Authority (CA) has its own key pair and signs server and client certificates. Distributing the CA’s root certificate allows clients to trust certificates signed by that CA.
  • TLS can authenticate servers (server certificates) and, when configured, clients (client certificates) — enabling mTLS.
In practice you will encounter three logical certificate types:
  • Server certificates — installed on services to secure their HTTPS endpoints.
  • Root/CA certificates — used to sign server and client certificates.
  • Client certificates — presented by clients when mutual TLS (mTLS) is required.
Naming conventions and file extensions
  • Files or extensions containing the word key or .key are private keys.
  • Files with .crt or .pem are typically public certificates (PEM-encoded).
  • Keep private keys secret and never commit them to public repositories.
Private keys usually contain the word key (as an extension or in the filename). Files without key are typically public certificates. Use this rule to avoid confusion when many files are present.
How these concepts map to a Kubernetes cluster A Kubernetes cluster has control-plane and worker nodes. All component-to-component and administrator-to-cluster communication should be encrypted and authenticated using TLS. In general:
  • Servers present server certificates to secure their endpoints.
  • Clients present client certificates (or other credentials) to prove identity when required.
Common Kubernetes components that require certificates Server-to-server and server-as-client scenarios
  • The kube-apiserver is a server for cluster clients, but it also acts as a client when connecting to other servers such as etcd or kubelets. In these flows etcd will see the API server as a client and may require client authentication.
  • You can reuse the API server’s serving certificate for outgoing client connections or issue a separate client certificate for the API server. Using separate certs helps separate concerns and simplifies rotation and auditing.
Grouping of certificates
  • Client certificates: used by components and users to authenticate to the kube-apiserver.
  • Server certificates: used by services (kube-apiserver, etcd, kubelet) to secure their HTTPS endpoints.
Kubernetes CA(s) Kubernetes requires at least one Certificate Authority for the cluster. Common patterns:
  • Single CA for all components (simpler but less isolation).
  • Multiple CAs (e.g., separate CA for etcd and a different CA for control-plane components) for improved isolation and scoped trust.
Each CA has its own certificate and private key (commonly named ca.crt and ca.key). Server and client certificates are generated and signed by the CA so that components trust one another.
An infographic showing the Kubernetes certificate layout with a Certificate Authority at the top. It groups client and server .crt/.key pairs (admin, kube-apiserver, etcd, kubelet, kube-scheduler, controller-manager, kube-proxy) into labeled boxes.
Next steps
  • Generate a CA private key and certificate (e.g., ca.key / ca.crt).
  • Create certificate signing requests (CSRs) for each component and sign them with the CA.
  • Discuss Subject Alternative Names (SANs) and Common Name (CN) usage — note that SANs are authoritative for hostname/IP verification in modern TLS clients; CN is deprecated for that purpose.
  • Plan for certificate rotation, secure storage, and revocation strategies.
Always protect private key files (e.g., *.key and *-key.pem). If a private key is compromised, any certificate relying on it must be revoked and replaced.
Further reading and references

Watch Video