Skip to main content
In this guide, you’ll learn how to encrypt and authenticate all traffic in a Kubernetes cluster using TLS. We’ll cover:
  • The role of keys, certificates, and Certificate Authorities (CAs)
  • TLS requirements for Kubernetes control plane and data plane
  • Mapping server and client certificates to Kubernetes components
  • Best practices for generating and signing certificates
By the end, you’ll understand how to implement mutual TLS (mTLS) across every communication channel in your cluster.

​
1. TLS Fundamentals: Keys, Certificates, and CAs

Before diving into Kubernetes-specific details, let’s recap the core concepts:
  • Public/Private Key Pair
    Each entity (server or client) generates a private key and a corresponding public key.
  • Server Certificates (server.crt, server.key)
    Used by services exposing HTTPS endpoints.
  • Client Certificates (client.crt, client.key)
    Prove a client’s identity to the server.
  • Certificate Authority (CA) (ca.crt, ca.key)
    Signs certificates and establishes a trust chain.

​
Naming Conventions

  • Public certificates: use .crt or .pem
  • Private keys: use .key or include “key” in the filename
  • Examples: apiserver.crt + apiserver.key, client.pem, client-key.pem

​
2. TLS Requirements in Kubernetes

All Kubernetes communications—intra-cluster or external—must be both encrypted and authenticated:
  1. Server Certificates
    Each service that exposes an HTTPS endpoint (API server, etcd, kubelet).
  2. Client Certificates
    Every client connecting to those services (kubectl, system components).
Mutual TLS ensures that both sides verify each other’s identity and encrypt data in transit.

​
3. Certificate Assignments for Kubernetes Components

​
3.1 Server-Side Certificates

ComponentCertificate FileKey File
API Serverapiserver.crtapiserver.key
etcd Serveretcd-server.crtetcd-server.key
Kubelet (worker)kubelet.crtkubelet.key
# Server certificate files on disk
ls /etc/kubernetes/pki/
# apiserver.crt   apiserver.key   etcd-server.crt   etcd-server.key   kubelet.crt   kubelet.key

​
3.2 Client-Side Certificates

ClientCertificate FileKey File
Administrator (kubectl)admin.crtadmin.key
Kube-Schedulerscheduler.crtscheduler.key
Kube-Controller-Managercontroller-manager.crtcontroller-manager.key
Kube-Proxykube-proxy.crtkube-proxy.key
# Client certificate files on disk
ls /etc/kubernetes/pki/
# admin.crt   admin.key   scheduler.crt   scheduler.key   controller-manager.crt   controller-manager.key   kube-proxy.crt   kube-proxy.key

​
Inter-Service Authentication

  • API Server → etcd: The API server acts as a client to etcd. You can reuse apiserver.crt/key or use a dedicated pair.
  • API Server → Kubelet: When the API server calls kubelet’s HTTPS endpoint, it presents a client certificate (either its serving cert or a separate client cert).
In each mTLS handshake, both parties authenticate and establish an encrypted channel, ensuring data integrity and confidentiality.

​
4. Certificate Authority and Signing Strategy

You need a CA to sign every server and client certificate. Kubernetes supports:
  • A single CA for all components
  • Multiple CAs (e.g., one CA for etcd, another for the rest)
In this walkthrough, we’ll use a single CA:
  • CA Public Certificate: ca.crt
  • CA Private Key: ca.key
Never store ca.key on nodes that aren’t fully secured. Loss of the CA key compromises your entire cluster.

​
4.1 CA-Managed Certificate Hierarchy

  1. Generate the CA key and certificate (ca.key/ca.crt).
  2. For each server and client:
    • Generate a CSR (Certificate Signing Request).
    • Sign the CSR with the CA key, specifying the proper Extended Key Usages (serverAuth or clientAuth).
  3. Distribute the signed certificates and corresponding keys to each component.

​
5. References and Further Reading

ResourceDescription
Kubernetes Official DocsDeep dive into components and TLS setup
Certificate Management (CA)Best practices for CA hierarchies
mTLS in Distributed SystemsBenefits of mutual TLS in microservices
By following these steps, you’ll ensure that every interaction within your Kubernetes cluster is both encrypted and authenticated, delivering a robust security posture for your applications and infrastructure.

Watch Video