PKI and Certificates

What is the complete PKI architecture required to bootstrap a Kubernetes control plane?

A Kubernetes cluster relies on a robust Public Key Infrastructure (PKI) to enforce strict mutual TLS (mTLS) authentication, authorize component communication, and encrypt data in transit across the entire architecture. By default, a fully compliant Kubernetes control plane does not rely on a single monolithic Certificate Authority (CA). Instead, it separates trust boundaries using multiple dedicated CAs and key pairs to minimize the blast radius of a compromised credential.

Here is the comprehensive architectural breakdown of the PKI required to bootstrap a Kubernetes control plane, detailing the distinct Certificate Authorities, the leaf certificates they sign, and how each component utilizes them.

The Certificate Authorities (CAs)

To establish a secure cluster, administrators (or bootstrapping tools like kubeadm) must generate three separate root CAs and one cryptographic key pair:

1. Kubernetes General CA (kubernetes-ca): The primary trust anchor for the cluster. It signs certificates for the main Kubernetes API and all core control plane and data plane clients.
2. etcd CA (etcd-ca): A dedicated CA strictly for the etcd backing store. Isolating this CA ensures that a compromised Kubernetes component cannot arbitrarily mint certificates to read or write directly to the database.
3. Front-Proxy CA (kubernetes-front-proxy-ca): Used exclusively for the API aggregation layer (Extension API servers). It establishes trust between the core kube-apiserver and aggregated APIs (like the Metrics Server).
4. Service Account Key Pair (sa.key and sa.pub): While not a CA, this RSA/ECDSA private and public key pair is a required PKI asset. It is used by the control plane to sign and verify JSON Web Tokens (JWTs) for ServiceAccounts.

---

Component-by-Component Certificate Breakdown

All generated certificates fall into specific key usage profiles: server auth (proving the server's identity to a client) and client auth (proving the client's identity to a server).

1. The API Server (kube-apiserver)

The kube-apiserver acts as the central hub and requires the most complex PKI configuration, acting as a server to users and a client to other control plane components.

• API Server Certificate (apiserver.crt / apiserver.key): Signed by the kubernetes-ca. This is a server certificate used to secure the main HTTPS endpoint (port 6443). It must include Subject Alternative Names (SANs) for the node's hostname, internal IP, the public load balancer IP, and the internal cluster Service IPs (e.g., kubernetes.default.svc).
• Kubelet Client Certificate (apiserver-kubelet-client.crt / apiserver-kubelet-client.key): Signed by the kubernetes-ca. This is a client certificate used by the API server to securely connect to the kubelet on worker nodes (e.g., for fetching logs or executing kubectl exec commands). It is typically assigned the system:masters organization (O) subject to grant it full administrative rights on the kubelet.
• etcd Client Certificate (apiserver-etcd-client.crt / apiserver-etcd-client.key): Signed by the etcd-ca. This client certificate allows the API server to authenticate itself to the etcd datastore to read and write cluster state.
• Front-Proxy Client Certificate (front-proxy-client.crt / front-proxy-client.key): Signed by the kubernetes-front-proxy-ca. When the API server proxies a request to an Extension API, it uses this client certificate to prove to the extension server that the request genuinely came from the core API server.

2. The etcd Datastore (etcd)

Because etcd contains the entire desired state and secrets of the cluster, its communications are heavily locked down using its own dedicated CA.

• etcd Server Certificate (etcd/server.crt / etcd/server.key): Signed by the etcd-ca. This server certificate is presented to clients (like the kube-apiserver) connecting to the etcd service.
• etcd Peer Certificate (etcd/peer.crt / etcd/peer.key): Signed by the etcd-ca. Because etcd is a distributed database, individual etcd nodes must continuously replicate data to one another. This certificate acts as both a server and client certificate to secure node-to-node (peer) communication.
• etcd Healthcheck Client (etcd/healthcheck-client.crt / etcd/healthcheck-client.key): Signed by the etcd-ca. A restricted client certificate used by local liveness probes (like the etcdctl tool running in the pod) to verify etcd health without granting it full administrative access.

3. Control Plane Controllers

The kube-controller-manager and kube-scheduler operate as clients to the API server. They do not serve their own secure endpoints for cluster operations; they only make requests.

• Controller Manager Client Certificate: Signed by the kubernetes-ca. The certificate subject is strictly tied to the system:kube-controller-manager Common Name (CN). This identity binds to a built-in ClusterRole that grants the exact permissions needed to run the core control loops.
• Scheduler Client Certificate: Signed by the kubernetes-ca. The certificate subject is tied to the system:kube-scheduler CN, authorizing it to watch unscheduled Pods and bind them to Nodes.

Architectural Note on the Controller Manager: The kube-controller-manager also needs access to the kubernetes-ca private key (ca.key) and the Service Account private key (sa.key). It requires the CA key to approve and sign CertificateSigningRequests (CSRs) for worker nodes, and the sa.key to sign the JWTs it issues to ServiceAccounts.

4. The Data Plane (Worker Nodes)

Every worker node must authenticate itself to the control plane.

• Kubelet Client Certificate (kubelet.conf): Signed by the kubernetes-ca. Used by the kubelet to authenticate to the API server. The Common Name must be in the exact format system:node:<nodeName>, and the Organization (O) must be system:nodes. This specific format triggers the Node Authorizer, ensuring the kubelet is only allowed to modify its own Node object and the Pods scheduled to it.
• Kubelet Server Certificate: Signed by the kubernetes-ca. The kubelet serves an HTTPS API (typically on port 10250) to accept commands from the API server. By default, kubeadm generates a self-signed certificate for this, but in strict production environments, it should be a CA-signed server certificate obtained via the CSR API during TLS bootstrapping.
• Kube-Proxy Client Certificate: Signed by the kubernetes-ca. Used by the kube-proxy daemon to watch the API server for changes to Services and Endpoints. It authenticates with the system:kube-proxy CN.

5. Administrator / Super-User Access

• Admin Client Certificate (admin.conf / super-admin.conf): Signed by the kubernetes-ca. For cluster administrators, certificates are generated with the Organization (O) set to system:masters. The Kubernetes RBAC engine hardcodes system:masters as a "break-glass" super-user group that bypasses all authorization checks.