Certificate Locations & Commands

Specify the location of all types of certs used and provide linux or kubectl commands used to check, renew and create the certs.

Default Certificate Locations

In a standard Kubernetes cluster initialized by kubeadm, the cryptographic assets are structurally segregated based on their function and the components that utilize them.

• Primary Control Plane Certificates (/etc/kubernetes/pki/): This directory houses the primary root Certificate Authority (CA) and the server/client certificates for the API server and front-proxy.
  • ca.crt / ca.key (Kubernetes General CA).
  • apiserver.crt / apiserver.key (API Server endpoint).
  • apiserver-kubelet-client.crt / apiserver-kubelet-client.key (API Server communicating to Kubelets).
  • front-proxy-ca.crt / front-proxy-client.crt (Aggregation layer routing).
  • sa.key / sa.pub (Service Account token signing key pair, though not technically a certificate).
• etcd Certificates (/etc/kubernetes/pki/etcd/): Because etcd manages its own trust boundary, its assets are nested in a dedicated subdirectory.
  • ca.crt / ca.key (etcd dedicated CA).
  • server.crt / peer.crt / healthcheck-client.crt (etcd server, node-to-node replication, and probe clients).
• Embedded Kubeconfig Certificates (/etc/kubernetes/): Certificates for core control loops and administrators are typically embedded directly as base64-encoded strings within kubeconfig files.
  • admin.conf / super-admin.conf (Cluster administrator credentials).
  • controller-manager.conf (Controller Manager identity).
  • scheduler.conf (Scheduler identity).
• Kubelet Certificates (/var/lib/kubelet/pki/): The worker node's kubelet manages its own client and serving certificates. If automatic certificate rotation is enabled, the active certificates are usually maintained here (e.g., kubelet-client-current.pem).

---

Commands to Check Certificates

You can inspect the validity and details of your cluster certificates using a combination of kubeadm, kubectl, and standard Linux tools.

1. Using kubeadm (Overall Expiration):

To quickly view the expiration dates and residual time for all control plane certificates managed by kubeadm, run:

kubeadm certs check-expiration

This command audits all files in /etc/kubernetes/pki and the embedded certificates in the core .conf files.

2. Using OpenSSL (Detailed Inspection):

To parse the cryptographic details (like Subject Alternative Names or exact validity dates) of a raw certificate file on disk, use openssl:

openssl x509 -text -noout -in /etc/kubernetes/pki/apiserver.crt

(You can also use this command with base64 --decode to inspect a certificate string extracted from a YAML manifest or a kubeconfig file).

3. Using kubectl (For embedded kubeconfig certs):

To extract and decode a certificate authority or client certificate embedded inside a kubeconfig file using kubectl and openssl:

kubectl config view --flatten --output 'jsonpath={.clusters.cluster.certificate-authority-data}' | base64 -d | openssl x509 -text -noout

This outputs the specific notBefore and notAfter dates to verify validity.

---

Commands to Renew Certificates

1. Renewing Control Plane Certificates (via kubeadm):

If you are performing a manual renewal instead of relying on the automatic renewal triggered during a Kubernetes upgrade, execute:

sudo kubeadm certs renew all

(Alternatively, you can renew a specific certificate by replacing all with the target name, such as apiserver).

Important: Because dynamic certificate reloading is not supported for all components, you must restart the static Pods (API server, controller manager, scheduler) by temporarily moving their manifests out of /etc/kubernetes/manifests/ and moving them back to force the kubelet to recreate them with the newly generated certificates.

2. Approving Kubelet Certificate Renewals:

When a kubelet approaches certificate expiration, it automatically generates a CertificateSigningRequest (CSR) against the API server. If your cluster does not auto-approve serving certificates, you must manually approve them:

kubectl get csr
kubectl certificate approve <certificate-signing-request-name>

---

Commands to Create Certificates

Certificates can be generated at the infrastructure layer (using CLI tools) or dynamically via the Kubernetes API.

1. Using the Kubernetes CSR API (kubectl):

To request a new client certificate securely without passing private keys over the network, you create the key locally, generate a CSR, and submit it to Kubernetes:

# 1. Generate the local private key and CSR
openssl genrsa -out myuser.key 3072
openssl req -new -key myuser.key -out myuser.csr -subj "/CN=myuser"

# 2. Submit the CSR to the Kubernetes API
cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: myuser
spec:
  request: $(cat myuser.csr | base64 | tr -d '\n')
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 86400
  usages:
  - client auth
EOF

# 3. Approve the request
kubectl certificate approve myuser

# 4. Download the finalized, signed certificate
kubectl get csr myuser -o jsonpath='{.status.certificate}' | base64 --decode > myuser.crt

2. Using kubeadm (Infrastructure Bootstrapping):

If you need kubeadm to generate specific components of the PKI manually (for example, when setting up an external CA), you can trigger the certificate generation phases directly:

sudo kubeadm init phase certs ca
sudo kubeadm init phase certs all

You can also use sudo kubeadm certs generate-csr to create CSRs for all known certificates managed by kubeadm if you intend to have them signed by a corporate external CA.

3. Using cfssl (Cloudflare's PKI Toolkit):

cfssl relies on JSON configuration files for profiles and generation.

# Generate the CA key and certificate
cfssl gencert -initca ca-csr.json | cfssljson -bare ca

# Generate a server key and certificate signed by the CA
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem --config=ca-config.json -profile=kubernetes server-csr.json | cfssljson -bare server

4. Using OpenSSL (Manual Generation):

For complete manual generation using standard openssl utilities:

# Generate CA
openssl genrsa -out ca.key 2048

# Generate Server Key and CSR
openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr -config csr.conf

# Sign the certificate using the CA
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 10000 -extensions v3_ext -extfile csr.conf -sha256