Talos client certificate expiry: diagnosing kubelet TLS handshake failures

Static PKI roles and expiry

In Talos v1.7–v1.9, each control-plane component — kubelet, controller-manager, scheduler, API server, etcd — authenticates with a client certificate signed by the cluster CA. Least-privilege is encoded statically in the certificate's OU (for example, system:node:<name>) and enforced by the API server's RBAC authorizer. Machine configs embed the full key pair, and the 1.8-era documentation treats rotation as a manual operational task, recommending external monitoring of NotAfter dates.

What needs a decision

The open item is operational posture. No background controller is documented to watch expiry in this line, so an expired certificate leads to failed TLS handshakes with no fallback to token auth until an operator re-issues. Whether releases after 1.9 added automatic rotation, and how external issuers such as Vault or cert-manager change the semantics, needs verification against the deployed version. Etcd peer certificates use a separate CA by default, which may surface expiry as a partition before any kubelet symptom.

Questions for review

1. Did any Talos release after 1.9 add automatic client-certificate rotation, or does expiry still require manual, per-node re-issuance?
2. If a node's static OU role must be narrowed after a suspected compromise, is re-issuing via machine config the only supported path?
3. Should etcd peer-CA certificates carry a separate expiry alert threshold from the cluster CA, given the different failure mode?