Why Kubernetes’ One‑Year Loopback Certificate Breaks and How the Community Is Tackling It

Background

Kubernetes kube-apiserver creates a LoopbackClient for internal calls such as fetching Services and Endpoints during startup. In a 2019 issue (apiserver LoopbackClient Server cert expired after 1 year) it was discovered that the self‑signed certificate generated for this client is hard‑coded to a one‑year validity period.

Certificate Generation

// create self‑signed cert+key with the fake server.LoopbackClientServerNameOverride
certPem, keyPem, err := certutil.GenerateSelfSignedCertKey(server.LoopbackClientServerNameOverride, nil, nil)
if err != nil {
    return fmt.Errorf("failed to generate self‑signed certificate for loopback connection: %v", err)
}
certProvider, err := dynamiccertificates.NewStaticSNICertKeyContent("self‑signed loopback", certPem, keyPem, server.LoopbackClientServerNameOverride)
if err != nil {
    return fmt.Errorf("failed to generate self‑signed certificate for loopback connection: %v", err)
}
// The certificate is valid for one year
validFrom := time.Now().Add(-time.Hour) // avoid clock‑skew flakes
maxAge := time.Hour * 24 * 365 // one‑year self‑signed certs

Detecting Expiration

You can query the health endpoint with a custom DNS entry to view the certificate details:

curl --resolve apiserver-loopback-client:6443:{Master_IP} -k -v https://apiserver-loopback-client:6443/healthz

The response shows a start date in 2019 and an expiration date in 2020, confirming the one‑year limit. Example output (truncated):

*  subject: CN=apiserver-loopback-client@1577103676
*  start date: Dec 23 11:21:16 2019 GMT
*  expire date: Dec 22 11:21:16 2020 GMT

Support Policy Impact

Kubernetes follows an “N‑2” support policy: only the three most recent minor releases (N, N‑1, N‑2) receive security and bug fixes. With a roughly three‑month release cadence, a cluster that runs a single kube‑apiserver instance for a full year is unlikely under normal upgrade practices.

A 2020 proposal (1498‑kubernetes‑yearly‑support‑period) extended the official support window from nine to fourteen months (twelve months of support plus a two‑month upgrade window). The release cadence was also changed by KEP‑2572 to three minor releases per year.

Alibaba Cloud ACK Adjustment

Alibaba Cloud’s ACK service modified the default LoopbackClient certificate expiration to ten years for clusters created after 15 Mar 2023 or upgraded to v1.20.11+. Clusters created before that date retain the one‑year limit, and administrators are advised to manually restart the API server pods to rotate the certificate.

External Efforts

Project klts (https://github.com/klts-io/kubernetes-lts) aims to maintain older Kubernetes versions, focusing on CVE back‑ports and critical issues.

Conclusion

The current fourteen‑month support cycle does not satisfy many users, and while the community acknowledges the need for a true LTS, it remains a work in progress. In the meantime, operators must monitor the LoopbackClient certificate and restart the API server when necessary.