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

​
3.2 Client-Side Certificates

​
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

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