What would you like to be added (User Story)?

As a user, I would like to not providing key from different CAs required by Kubernetes and Cluster API for security purposes. Certificate signing could be handled by an external issuer.

Detailed Description

Currently, ClusterApi supports the use of External CAs by providing them via secrets (cf. ClusterApi - Book). This is a good thing, but in my case, I don't want to provide it with my CAs's keys because I want to sign the various kubernetes certificates (client/server) externally.

Currently and according to my perception, ClusterApi's role concerning CA is only to provide them to the controlplane nodes with a cloud init, so that the Kubernetes bootstraper can sign the certificates it needs. For actions/verifications to the ApiServer in External CA mode, we (users) can provide a custom kubeconfig (cf. ClusterApi - Book).

Except for one thing (problem 1): the KubeadmControlPlane controller reconciles the members of the ETCD and needs a client certificate. To do this, if the the secret of CA ETCD is supplied with the key, the controller creates a client ETCD certificate, otherwise it considers that it is in External ETCD mode and looks for the client certificate in a secret named -apiserver-etcd-client.
In External CA and External Certificate Signing mode, we could provide the -apiserver-etcd-client, just as we do with kubeconfig.

Another problem (problem 2) also exists but is not blocking: when there is a join for a controlplane node, ClusterApi checks all External CA secrets (Proxy, Apiserver, ETCD and also SA) to ensure that they contain the tls.key. This check is problematic in External Certificate Signing mode, because we don't want to provide the CA keys at any point, but can be tackled by providing a dummy key.

The two problems are closely related: I can resolve the first issue by omitting the ETCD CA key from the secret, but that hit to the second issue since the key is missing — and the reverse..

The External Certificate Signing feature would therefore be in place if at least problem 1 is solved. Problem 2 is not blocking because there is a bypass but maybe we can tackled it also.

Anything else you would like to add?

No response

Label(s) to be applied

/kind feature
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.