Kubeadm "init" via a Root CA

[moshloop]

/kind feature request

The new --upload-certs option is great for joining additional control plane nodes, but it doesn't solve the problem of securely distributing certificates for use cases like Cluster API.

I think this could be solved by turning the problem around, and rather than distributing certificates followed a typical CSR model.

1. CAPI generates a new root CA for a child cluster
2. SA is created with CertificateSigningRequest rights (perhaps per new node with a very short TTL)
3. kubeadm --init --token <> --management-api-server <>
4. kubeadm generates and submits CSR, requesting signing by the child cluster CA
5. Certificate Approval Controller approves CSR's, creating new intermediate CA's for every controller node.
6. Kubeadm specifies the child cluster CA instead of its own intermediate CA when configuring the components applicable --cafiles

I think this will also need changes to k/k Certificate Controller to support more than 1 root CA, or an out of tree controller.

[neolit123]

The new --upload-certs option is great for joining additional control plane nodes, but it doesn't solve the problem of securely distributing certificates for use cases like Cluster API.

the problem needs a better definition. could you provide more detail?

what prevents CAPI to copy the root CA to the primary kubeadm init node, treat it as external CA (kubeadm supports that) and let the other CP nodes to join using --certificate-key?

I think this will also need changes to k/k Certificate Controller to support more than 1 root CA, or an out of tree controller.

this change in the in-tree controller might not make it in, or it might after 1-2 years of discussion.

/assign @detiber @vincepri
cc @fabriziopandini

[moshloop]

what prevents CAPI to copy the root CA to the primary kubeadm init node

Copying the certificates to the primary nodes is what CAPA/CAPV does currently, however, the method used to get the keys on the host is insecure (user-data) and starts creating other issues around user-data size limitations (kubernetes-sigs/cluster-api-provider-aws#847 (comment))

This doesn't strictly need to be done in kubeadm, it could be implemented in a "wrapper" around kubeadm or via something like SPIRE

this change in the in-tree controller might not make it in, or it might after 1-2 years of discussion.

I agree, the only reason I would even suggest doing it in k/k, is to not add any dependencies for kubeadm - after thinking about it kubeadm could just fallback to using a single root CA (with a warning that cross-talk between clusters will be possible)

[neolit123]

This doesn't strictly need to be done in kubeadm, it could be implemented in a "wrapper" around kubeadm or via something like SPIRE

it does seem like a problem that can be resolved higher up the stack.

[neolit123]

closing as something that can be resolved by tools wrapping kubeadm.
on the kubeadm side we might support alternative certificate distribution methods in a "kubeadm operator":
#1698