Much like bootimages, we cannot directly manage all cluster architectures automatically. For clusters that do not use machineset backed node scaling, whichever method they use to generate the stub/full ignition (likely lives outside the cluster) will have to be updated by hand.

When we detect the on-cluster CAs are about to expire (80% expiry) and no machinesets are available in the cluster to auto update, we should add some way to notify the user that the rotation has happened. (An alert seems too extreme, best case scenario would be some status that needs to be acknowledged by the user, but I'm not sure such a mechanism exists). One option is just to add some MCN status or node annotation or pool status/warning, that can be used to debug later but is not directly surfaced.

Alternatively, we could just add some warning via the MCS when it gets a new join request, if the old certs have expired. Unfortunately the MCS also does not know if the client cert will be correct.

Update(11/5/2024):

After discussion with jerzhang@redhat.com about the MVP PR, we came to the conclusion that this can be rolled into the boot image update epic targeting non MachineSet based clusters. Since that work will require enforcing a "skew acknowledgement requirement" from the admin before they can scale up/upgrade clusters, we will also put in a check to acknowledge that CAs are up to date in their stub ignition.

The MCS CA on a non MachineSet managed cluster can be found in the root-ca configmap, in the kube-system namespace. It is also stored in the controllerconfig object(called machine-config-controller) under status.controllerCertificates field. To rotate the certs, the admin will have to use an oc command, described in this KB article.