Add support for bootsrapping TLS from a rest.Config

[cpuguy83]

This uses a rest.Config to bootstrap TLS for the http server, webhook
auth, and the client.

This can be expanded later to do other kinds of TLS bootstrapping. For
now this seems to get the job done in terms of what VK expects for
permissions on the cluster.

[cpuguy83]

To test this locally:

Token Auth

$ make build
Building...
CGO_ENABLED=0 go build -ldflags '-extldflags "-static"' -o bin/virtual-kubelet  -ldflags='-X "main.buildVersion=v1.5.0-41-g0127d428" -X "main.buildTime=2022-08-30-22:27 UTC"' ./cmd/virtual-kubelet
$ token="$(kubectl config view --minify --raw --output 'jsonpath={.users[0]}' | jq -r .user.token)"
$ bin/virtual-kubelet --kubeconfig ~/.kube/config  --provider=mock --provider-config hack/skaffold/virtual-kubelet/vkubelet-mock-0-cfg.json --nodename=vkubelet-mock-0 &
INFO[0000] Waiting for controller to be ready            node=vkubelet-mock-0 operatingSystem=linux provider=mock watchedNamespace=
INFO[0000] Pod cache in-sync                             node=vkubelet-mock-0 operatingSystem=linux provider=mock watchedNamespace=
INFO[0000] receive GetPods                               method=GetPods node=vkubelet-mock-0 operatingSystem=linux provider=mock watchedNamespace=
INFO[0000] starting workers                              node=vkubelet-mock-0 operatingSystem=linux provider=mock watchedNamespace=
INFO[0000] started workers                               node=vkubelet-mock-0 operatingSystem=linux provider=mock watchedNamespace=
INFO[0000] Ready                                         node=vkubelet-mock-0 operatingSystem=linux provider=mock watchedNamespace=
$ curl -k -H "Authorization: bearer ${token}" https://localhost:10250/stats/summary
{"node":{"nodeName":"vkubelet-mock-0","startTime":"2022-08-30T22:04:39Z"},"pods":null}
$

Certificate Auth

$ make build
Building...
CGO_ENABLED=0 go build -ldflags '-extldflags "-static"' -o bin/virtual-kubelet  -ldflags='-X "main.buildVersion=v1.5.0-41-g0127d428" -X "main.buildTime=2022-08-30-22:27 UTC"' ./cmd/virtual-kubelet
$ bin/virtual-kubelet --kubeconfig ~/.kube/config  --provider=mock --provider-config hack/skaffold/virtual-kubelet/vkubelet-mock-0-cfg.json --nodename=vkubelet-mock-0 &
INFO[0000] Waiting for controller to be ready            node=vkubelet-mock-0 operatingSystem=linux provider=mock watchedNamespace=
INFO[0000] Pod cache in-sync                             node=vkubelet-mock-0 operatingSystem=linux provider=mock watchedNamespace=
INFO[0000] receive GetPods                               method=GetPods node=vkubelet-mock-0 operatingSystem=linux provider=mock watchedNamespace=
INFO[0000] starting workers                              node=vkubelet-mock-0 operatingSystem=linux provider=mock watchedNamespace=
INFO[0000] started workers                               node=vkubelet-mock-0 operatingSystem=linux provider=mock watchedNamespace=
INFO[0000] Ready                                         node=vkubelet-mock-0 operatingSystem=linux provider=mock watchedNamespace=
$ kubectl config view --minify --raw --output 'jsonpath={.users[0].user.client-key-data}' | base64 -d > key.pem
$ kubectl config view --minify --raw --output 'jsonpath={.users[0].user.client-certificate-data}' | base64 -d > cert.pem
$ curl -k --cert cert.pem --key key.pem https://localhost:10250/stats/summary
{"node":{"nodeName":"vkubelet-mock-0","startTime":"2022-09-01T21:25:53Z"},"pods":null}

[pires]

s/reset/rest

[pires]

IIUC the x509 artifacts used for VK to authenticate as a client are the same used to serve the (virtual-)kubelet API?

[cpuguy83]

Yes that's what it is currently doing.

[pires]

In the PR description, TLS authentication output doesn't seem to be relying on TLS for authentication. I trust it's working, just raising awareness.

[cpuguy83]

Eek, apparently my copy didn't take effect.

[cpuguy83]

Fixed that description.

[pires]

Overall LGTM.

[cpuguy83]

CI is failing most likely due to the test not using the right certs. I need to look into where this is happening.

[enj]

I have not looked closely but assuming the CA used for signing serving certificates and client certificates is the same is generally not valid.

[pires]

Unless I'm missing something here, the configuration is passed by the user.

[hasan4791]

When can we expect this PR to be merged!!

[hasan4791]

Hello @cpuguy83, Is this still wip or shall i take it forward?

[cpuguy83]

I do not have cycles for this.
If someone wants to take it, please feel free.