Kubernetes is distributed system that is composed of many interconnected components.
- Control Plane or Master Node : API Server, etcd, Scheduler, Controller Managers, Cloud Controllers
- Data Plane (Worker Nodes): kubelet and kube-proxy agents
Many of these components need to communicate securely with each other, like a normal users will do when interacting with the cluster via tools like kubectl or K8Studio. In my opinion many kubernetes operator don’t really know how this works, and understanding this internal communication is crucial for managing and protecting your cluster.
So we are going to cover a few things here :
- How Kubernetes components establish secure connections
- The mechanisms behind authentication and authorization
The intention of this post is for you to have a clearer understanding of how Kubernetes secures its internal communications and how to leverage that knowledge to harden your infrastructure.
1. Components needed to create a secure Communication.
Why reinvent hot water!, Kubernetes uses TLS to make internal and extarnal comunication secure and private.
The communication is than in a client server fashion. Normally a client asking the server for information a to do something. Good example of this communications happens When the kube-proxy connect to the kubeApi to watch changes in services to update the Iptables or IPVS
To establish secure this comunication this is what is needed:
Let’s start with the communication between the API Server and Kube-Proxy.
1.Server Component(Ex:kube-api) :
Requires a server certificate signed by the cluster’s Certificate Authority (CA), consisting of:
- apiserver.key – the private key uses to encrypt data sent.
- apiserver.crt – the server certificate (public key + CA signature)
- Also requires the CA certificate (ca.crt), which is used to verify the authenticity of client certificates during mutual TLS.
2. Client Certificate(kube-proxy) :
Kube-proxy can authenticate to the API server using a client certificate signed by the cluster’s Certificate Authority (CA).This includes:
client.key – the private key
client.crt – the client certificate (public key + CA signature)
Kube-proxy also requires the CA certificate (ca.crt) to verify the API server’s certificate during the TLS handshake.
3. Certificate Authority (CA) :
Signs client and server certificates using its private key ca.key.
Provides the public certificate ca.crt, which is distributed to cluster components so they can verify the authenticity of certificates presented by peers.
2. How Certificates Enable Secure Communication
Step 1: TLS Handshake Initiation
- kube-proxy connects to https://<api-server>:6443.
- The TLS handshake begins:
- ClientHello: kube-proxy sends supported TLS versions, ciphers, and random data.
- ServerHello: API server responds with its apiserver.crt and handshake parameters.
Step 2: Server Certificate Verification (by Client)
- kubectl uses the cluster’s ca.crt to verify that the server certificate is signed by the trusted CA.
- If verification fails, the connection is rejected.
Step 3: Client Certificate Verification (by Server)
When mutual TLS (mTLS) is enabled (used by internal Kubernetes components):
- kubectl sends its client.crt to the API server.
- API server verifies:
- Is client.crt signed by the cluster CA?
- Is it valid (not expired or revoked)?
- Does the CN (Common Name) or user in the cert have the required RBAC permissions?
The API server uses its trusted CA bundle (usually /etc/kubernetes/pki/ca.crt) to verify the client certificate.
Step 4: Key Exchange & Secure Channel
Once both sides trust each other:
- They perform a Diffie-Hellman or ECDHE key exchange to generate a shared session key.
- All further communication is encrypted with symmetric encryption using this session key.
Step 5: Authentication and Authorization
- TLS verifies identity (Authentication).
- Kubernetes then checks RBAC rules to ensure the user (from the client.crt CN) is authorized to perform the requested action.
3. Role of the Certificate Authority (CA)
The CA is the trust anchor for the cluster.
- Private Key → Used to sign certificates
- Public Key (ca.crt) → Used to verify those signatures
4. How Verification Works
Every certificate contains:
Subject info (CN, O)
Public key
Signature by CA
When a client receives a certificate:
Extracts the signature
Hashes the certificate’s contents
Uses the CA public key to verify the signature
If it matches → Certificate is authentic and untampered.
4. Detailed Example: kubectl get pods
- kubectl → API server (TLS handshake starts)
- API server sends apiserver.crt
- kubectl verifies certificate with ca.crt and checks the SAN = kubernetes.default.svc
- API server requests a client certificate
- kubectl sends client.crt
- API server:
- Verifies client.crt against its CA bundle
- Extracts CN = my-user → Maps to Kubernetes user
- Checks RBAC: Can my-user list pods?
If authorized → API server returns the pod list, encrypted over TLS.
Let me know if you find this useful.