Skip to content

6.04 TLS in Kubernetes

1️⃣ Why TLS is Critical in Kubernetes

A Kubernetes cluster has:

  • Control plane nodes
  • Worker nodes
  • Internal components communicating constantly
  • External users (admins, automation, CI/CD)

All communication must be:

  • 🔐 Encrypted
  • ✅ Authenticated
  • 🛡 Protected against impersonation

Danger

Without TLS, attackers can intercept API requests, steal credentials, or manipulate cluster state.

2️⃣ Types of Certificates in Kubernetes

Kubernetes uses three main certificate types:

Type Purpose Example Files
Server Certificates Secure HTTPS endpoints apiserver.crt, etcd-server.crt
Client Certificates Authenticate clients admin.crt, scheduler.crt
Root Certificate (CA) Signs all certs ca.crt, ca.key

📁 Naming Convention

File Type Pattern
Certificate (Public) .crt, .pem
Private Key .key, -key.pem

Tip

If filename contains "key", it is usually a private key.

3️⃣ Kubernetes TLS Architecture

🔹 API Server

The kube-apiserver:

  • Exposes HTTPS endpoint
  • All components connect to it
  • Requires serving certificate

Example:

apiserver.crt
apiserver.key

🔹 ETCD Server

  • Stores cluster state
  • Only API server connects to it
  • Requires its own server certificate
etcd-server.crt
etcd-server.key

🔹 Kubelet

  • Runs on each node
  • Exposes HTTPS endpoint
  • API server connects to it
kubelet.crt
kubelet.key

4️⃣ Client Certificates in Kubernetes

Clients connecting to API Server:

Component Certificate
Admin (kubectl) admin.crt
Scheduler scheduler.crt
Controller Manager controller-manager.crt
Kube Proxy kube-proxy.crt
API Server (to ETCD) Client certificate

Note

From the API server’s perspective, scheduler and controller-manager are just clients.

5️⃣ Certificate Authority (CA)

Every cluster requires at least one CA.

ca.crt
ca.key

The CA:

  • Signs all server certificates
  • Signs all client certificates
  • Establishes trust chain

🔹 Optional: Separate ETCD CA

Production setups often use:

  • One CA for cluster
  • One CA specifically for ETCD

Success

Separating ETCD CA improves security isolation.

6️⃣ How TLS Works Inside Kubernetes

Admin Access Flow

  1. Admin runs kubectl
  2. Admin presents client certificate
  3. API server validates against CA
  4. Secure session established

API Server → ETCD Flow

  1. API server connects to ETCD
  2. API server presents client certificate
  3. ETCD validates using CA
  4. Secure encrypted connection established

7️⃣ Production Best Practices

✅ DO

Success

  • Use separate CA for ETCD
  • Restrict access to ca.key
  • Rotate certificates periodically
  • Use short certificate lifetimes
  • Protect private keys (chmod 600)
  • Use kubeadm or cert-manager for automation
  • Enable TLS 1.2+ only
  • Enable API audit logs

❌ DON'T

Danger

  • Do NOT share ca.key
  • Do NOT use self-signed certs in production
  • Do NOT disable TLS verification
  • Do NOT use expired certificates
  • Do NOT reuse admin certificates for automation
  • Do NOT store private keys in Git or container images

8️⃣ Mutual TLS (mTLS)

Kubernetes uses mutual TLS internally:

  • Server verifies client
  • Client verifies server

Used between:

  • API server ↔ Kubelet
  • API server ↔ ETCD
  • Control plane components

Tip

Kubernetes internal security is built entirely on mutual TLS.

🎯 Final Summary

  • Kubernetes secures everything using TLS
  • API server is central trust anchor
  • All components use mutual TLS
  • CA signs both server and client certificates
  • Production security depends on proper key management

Quote

In Kubernetes, trust begins at the Certificate Authority.
Protect the CA, protect the cluster.