Skip to main content
This lesson explains how TLS certificates secure communication inside a Kubernetes cluster. It covers public/private keys, certificate authorities (CAs), and the certificate types Kubernetes components use. After this overview you’ll understand which components need which certificates and how to organize them for easier management.

​
Quick recap: certificates and keys

  • Server certificates — used by servers to identify themselves (commonly *.crt or *.pem).
  • Root certificates — the CA’s certificate and private key used to sign other certificates (ca.crt and ca.key).
  • Client certificates — used by clients to authenticate to servers (commonly *.crt paired with a *.key).
Naming conventions vary, but a consistent scheme reduces errors:
Use consistent filenames — for example, api-server.crt and api-server.key — to reduce confusion. Filenames shown in this lesson are illustrative; your cluster may use different names.
Keep private keys (*.key, or any filename containing key) secure and access-controlled. If a private key is leaked, certificates signed by that key must be revoked and reissued.

​
Why TLS matters in Kubernetes

Kubernetes nodes and components exchange sensitive data and control commands. Every connection between:
  • control plane components and worker nodes,
  • components and etcd,
  • administrators (kubectl/REST clients) and the API server,
should be both encrypted and authenticated. TLS provides confidentiality (encryption) and authentication (via certificates). General rules:
  • Servers must present server certificates so clients can verify identity.
  • Clients present client certificates when the server requires client authentication.
A stylized diagram showing a Kubernetes control plane (kube-apiserver and kube-scheduler) on a master node connected securely to an admin and several worker servers using padlock icons and certificate labels. The top-right notes "Server Certificates for Servers" and "Client Certificates for Clients."

​
Main server and client components

Below is a concise mapping of common Kubernetes components to the certificate files they typically require. Notes:
  • Some components act as both servers and clients. For example, the kube-apiserver is a server for clients like kubectl, and it is a client when it connects to etcd or kubelets.
  • Components may reuse a single certificate for both serving and client authentication, or they may use separate certificate pairs depending on security policies.

​
Examples of server-as-client interactions

  • kube-apiserver → etcd: The API server connects to etcd. It may reuse its serving certificate (api-server.crt / api-server.key) or use a distinct client certificate issued to the API server for authentication to etcd.
  • kube-apiserver → kubelets: The API server connects to kubelets on worker nodes. These connections can use the kube-apiserver’s serving certificate or a separate client certificate.

​
Organizing certificates

Group certificates by purpose to simplify management and rotation:
  • Client certificate set: certificates used by users and control-plane components to authenticate to the API server (e.g. admin.crt, scheduler.crt, kube-proxy.crt).
  • Server certificate set: certificates used by services exposing HTTPS endpoints (e.g. api-server.crt, etcdserver.crt, kubelet.crt).
  • CA certificate(s): at least one CA is required to sign cluster certificates. You can use one CA for the whole cluster or multiple CAs (for example, a separate etcd CA for additional isolation).
If you use a separate CA for etcd, the etcd server certificates and the API server’s client certificate for etcd should be issued by that etcd CA. For this lesson we assume a single CA with the filenames ca.crt and ca.key.
An infographic diagram of Kubernetes TLS certificates, showing a Certificate Authority at the top and grouped client and server certificates. Each group lists component names (admin, kube-apiserver, kubelet, controller-manager, scheduler, etcd, kube-proxy) with their .crt and .key filenames.

​
What’s next

Now that you understand which certificates are required and how to organize them, the next step is generating a CA and creating certificate signing requests (CSRs) for each component, then signing those CSRs with the CA to produce the required *.crt and *.key pairs. Typical workflows include using openssl or cfssl to generate keys/CSRs and a CA to sign them, or leveraging automated tooling (e.g., cert-manager) for issuance and rotation.

Watch Video