PKI: KCSA practice questions

A public key infrastructure binds identities to key pairs through certificates signed by a trusted certificate authority. Kubernetes leans on it heavily: TLS protects traffic between components, and client certificates are one of the ways a caller proves who it is to the API server.

The list of certificates a cluster needs is long. On the server side there are certificates for the API server endpoint, for the etcd server and for each kubelet. On the client side, each kubelet authenticates to the API server, the API server authenticates to etcd and to kubelets, and the controller manager, scheduler and kube-proxy each have client certificates for talking to the API server. etcd also uses mutual TLS between clients and peers. A kubeadm cluster typically has three CAs: the general Kubernetes CA (ca.crt and ca.key), a separate etcd CA and a front-proxy CA, plus a key pair used to sign ServiceAccount tokens. kubeadm stores these under /etc/kubernetes/pki by default, with administrator kubeconfig files such as admin.conf in /etc/kubernetes.

Issuing a certificate for a new human user illustrates the pieces. First generate a private key with openssl genrsa (the official walkthrough uses openssl genrsa -out myuser.key 3072, and the key must stay private because anyone holding it can impersonate the user). Then create a certificate signing request with openssl req, setting CN to the user name and O to a group, because the API server reads those fields as the user's name and group membership. Wrap the CSR, base64-encoded, in a CertificateSigningRequest object from the certificates.k8s.io API with signerName kubernetes.io/kube-apiserver-client, an optional expirationSeconds and the client auth usage. An administrator approves it with kubectl certificate approve (or rejects it with kubectl certificate deny); that signer is never auto-approved by the controller manager. The issued certificate appears base64-encoded in .status.certificate, and kubectl config set-credentials with --client-certificate and --client-key adds it to a kubeconfig. The certificate only authenticates; RBAC still decides what the user may do.

Certificates expire, so rotation is part of operations. kubeadm certs check-expiration lists every certificate and its remaining lifetime, and kubeadm certs renew renews them, individually or with renew all. kubeadm also renews all certificates during a control plane upgrade, which is enough for clusters upgraded at least once a year. Kubelet serving certificates generated by kubeadm expire after one year; with rotateCertificates enabled, the kubelet requests new ones through CSRs, which must be approved.

Integrity checks apply to binaries as well as certificates. The Kubernetes download instructions publish a SHA-256 checksum for each binary, and comparing it with sha256sum detects corrupted or tampered downloads before they run on a node.