Default 1-year expiry — the clock that is always running

Every kubeadm-managed certificate is issued with a 1-year default validity. That default is the cluster’s most predictable time bomb: a year from kubeadm init, every cert expires on the same day, and the cluster’s authentication breaks. This lesson walks the default, the risk window, and the rotation cadence.

The 1-year default

Run kubeadm certs check-expiration on any healthy cluster created within the last year:

sudo kubeadm certs check-expiration

CERTIFICATE                          EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
admin.conf                          Aug 16 10:00:00 2027 UTC  364d            ca                      no
apiserver                           Aug 16 10:00:00 2027 UTC  364d            ca                      no
apiserver-kubelet-client            Aug 16 10:00:00 2027 UTC  364d            ca                      no
controller-manager.conf             Aug 16 10:00:00 2027 UTC  364d            ca                      no
scheduler.conf                      Aug 16 10:00:00 2027 UTC  364d            ca                      no
etcd-ca                             Aug 16 10:00:00 2027 UTC  364d            etcd-ca                 no
etcd-healthcheck-client             Aug 16 10:00:00 2027 UTC  364d            etcd-ca                 no
etcd-peer                           Aug 16 10:00:00 2027 UTC  364d            etcd-ca                 no
etcd-server                         Aug 16 10:00:00 2027 UTC  364d            etcd-ca                 no
front-proxy-ca                      Aug 16 10:00:00 2027 UTC  364d            front-proxy-ca          no
front-proxy-client                  Aug 16 10:00:00 2027 UTC  364d            front-proxy-ca          no

Every cert expires on the same date. The cluster has a single hard deadline.

Why 1 year

The 1-year default is a balance between:

• Operational simplicity. A single calendar event per year is easier than 12 monthly rotations.
• Crypto rotation. Annual rotation is enough to bound the window of compromise for any one key.
• Compliance. Most regulatory frameworks (PCI-DSS, SOC 2, FedRAMP) accept 1-year cert validity.

Some teams shorten the validity for compliance reasons or to enforce rotation discipline. That is a fine choice, but it raises the operational cost of the rotation.

The risk window

The operational risk window is the period during which a cert expiry would cause an incident. The window has three regions:

gantt
    title Cert lifecycle risk window
    dateFormat  YYYY-MM-DD
    section Safe
    Issued and current       :done,    a1, 2026-08-16, 270d
    section Watch
    Within 30 days of expiry :active,  a2, 2027-05-18, 30d
    section Action
    Within 7 days of expiry  :crit,    a3, 2027-06-10, 7d
    section Fail
    Expired                  :         a4, 2027-06-17, 365d

• 0–270 days (safe): no operator attention required beyond the calendar.
• 270–335 days (watch): active monitoring, schedule the renewal in the next maintenance window.
• 335–357 days (action): renew within 7 days. A failure to renew now is an incident.
• 357+ days (fail): expired certs cause cascading failures; the cluster is no longer functional.

The rolling renewal

kubeadm certs renew extends the cert’s validity without rotating the key (by default — see Lesson 5 for forced key rotation). The renewal is incremental:

sudo kubeadm certs renew all

[renew] Reading configuration from the cluster...
[renew] FYI: You can look at this config with the 'kubectl get' command
[renew] FYI: openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates
certificate with no expiry

Wait, the renewal output is silent on success. Verify:

sudo kubeadm certs check-expiration

CERTIFICATE                          EXPIRES                  RESIDUAL TIME
apiserver                           Aug 16 10:00:00 2028 UTC  364d

The cert is now valid for another year. The date is relative to the renewal day, not the original init.

The static pod restart

Renewing the API server’s serving cert requires the API server to reload the cert. The kubelet does this by restarting the static pod when the manifest changes. The restart is brief (seconds), but the API server is offline during that window.

sequenceDiagram
    participant O as Operator
    participant K as kubeadm
    participant KL as kubelet
    participant AS as API server static pod
    O->>K: sudo kubeadm certs renew all
    K->>K: rotate cert files in /etc/kubernetes/pki
    K->>KL: write new static pod manifest hash
    KL->>AS: restart static pod
    AS-->>O: API server back in seconds

Production clusters route the API server through a load balancer that drops the brief outage; clients see a 503 and retry.

Shortening validity

To shorten the validity (e.g., to 90 days for compliance), edit the kubeadm ClusterConfiguration before init:

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
---
apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
localAPIEndpoint:
  advertiseAddress: 10.0.1.10
nodeRegistration:
  criSocket: unix:///var/run/containerd/containerd.sock
---
apiVersion: kubelpelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
---
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration

The duration is not directly configurable in kubeadm 1.34.x. Workarounds:

• External PKI. Use cert-manager or an external CA and issue shorter certs. The cluster’s CA stays the same; individual certs rotate via the operator.
• Manual rotation. Run kubeadm certs renew more often (every 90 days).
• Renovate. A tool that automates renewal across the cluster.

The kubelet’s client cert

The kubelet’s client cert (not the API server’s cert) is issued by the kube-controller-manager’s CSR signer. Unlike the API server’s cert, the kubelet cert is rotated by the kubelet itself when it reaches 75% of its validity:

flowchart LR
    A[kubelet at 75% of cert life] --> B[submit CSR to API server]
    B --> C[kube-controller-manager signs]
    C --> D[kubelet installs new cert]

This rotation is automatic; the operator does not need to renew the kubelet’s cert manually. The cert chains to the cluster CA, so as long as the CA is valid, the kubelet cert rotates freely.

The cross-course offline clock

The 1-year default is a constraint discovered in many systems. The Linux course covers key rotation for SSH host keys (ssh-keygen -R). The VyOS course covers certificate rotation for IPsec. The principle is the same: every cert has a clock, the clock always expires, and the rotation must be scheduled.

Quiz

Production discipline

• Calendar the 1-year mark. Every cert expires on the same day; rotate on schedule.
• Watch window: 30 days. Schedule the renewal at 30+ days residual.
• Action window: 7 days. Renew within 7 days of expiry.
• Followers first, leader last. Contain the static pod restart to the leader.
• Snapshot before renewal. Insurance against static pod misconfiguration.
• External monitoring. Prometheus probe_ssl_earliest_cert_expiry alert at 30/15/7 days.

The 1-year default is the cluster’s annual planning event. Operating it well is keeping the calendar current and the renewal rehearsed.