Pires

Just to make sure we're on the same page, are you suggesting that changes need to be applied to both VK **and** cloud-provider(s) code?

Unfortunately, the change I proposed upstream was not accepted. Here's the current state of things https://github.com/kubernetes/cloud-provider/issues/35

When you say providers, you mean the cloud providers (implementations), right? Not the VK providers.

Thank you for trying to help here, but my hunch is this is unreasonable. And even if it is and cloud-provider code owners would do it, we can't guarantee VK...

Re-assigning to me since I don't see any activity from @VDuleb.

What I propose is to clearly identify the VK incompatibility w/ CCM in docs and even print a warning during VK initialization. @cpuguy83 wdyt?

The options listed are steps that require human (cluster admin) intervention. Even TLS bootstrapping must be triggered by a human being somehow, e.g. provision bootstrap kubeconfig and run `./kubelet --bootstrap-kubeconfig

Sure, you can use any CA out-of-band for as long as: - it is the Kubernetes CA (`kube-apiserver --client-ca-file`) - LE allows for `CN` and `O` to be what you...

Forgot to mention that if the `Node` authorizer is enabled in `kube-apiserver`, TLS is the only way. Edited issue to include this.

So far, the comments only covered client authentication but not the VK-API serving aspect. The `kubelet` exposes a configuration option `serverTLSBootstrap` that allows for it to request a certificate to...