--kubelet-insecure-tls is still present

[avoidik]

Hi,

I'm wondering whether the following line increases said security, could you please comment?

secure-metrics-server/secure-metrics-server.sh

Line 131 in 87c714b

value: --kubelet-insecure-tls

[jenting]

The metrics-server is a server as part of kube-apiserver, also a client to gathering the CPU/memory from kubelet server.

The repo makes the metrics-server server part secure with TLS.

Since However, K8s distro (like kubeadm) bootstrapped cluster, the kubelet server are run in self-signed certificate in each nodes. Therefore, we can't make the metrics-server client run with TLS.

[avoidik]

much appreciated for your answer and explanation, we've been doing certificates resigning to specifically get rid of the --kubelet-insecure-tls flag, so that the certificate becomes trusted by Kubernetes CA, isn't it?

[jenting]

Yes, you could resign all node's kubelet server certificate issued by your trusted CA.
After that, the flag --kubelet-insecure-tls could be drop.

[dahrens]

One might also let the kubelet do the job, when spinning up the cluster using this configuration:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
serverTLSBootstrap: true

If you pass this configuration to kubeadm, each kubelet issues a CSR like you do in your script. Those can be approved in the same manner and you can omit the flag --kubelet-insecure-tls.

[jenting]

One might also let the kubelet do the job, when spinning up the cluster using this configuration:

apiVersion: kubelet.config.k8s.io/v1beta1

kind: KubeletConfiguration

serverTLSBootstrap: true

If you pass this configuration to kubeadm, each kubelet issues a CSR like you do in your script. Those can be approved in the same manner and you can omit the flag --kubelet-insecure-tls.

Thank you, correct!

You could reference my another project https://github.com/SUSE/kucero if you are interested which focus on rotates kubeadm-managed and kubelet client&server certificates automatically.

[avoidik]

@jenting that's another great option to address kubernetes/kubeadm#1602

[avoidik]

with regard to my original question, do we really need these lines after all?

https://github.com/jenting/secure-metrics-server/blob/main/secure-metrics-server.sh#L129-L131

or maybe README.md file should have step 6 to omit the flag with kubectl patch?

[jenting]

Well, if you have prepared

• the Kubelet CA
• enabled the kubelet serverTLSBootstrap: true
• manually sign CSR or use https://github.com/SUSE/kucero

then the https://github.com/jenting/secure-metrics-server/blob/main/secure-metrics-server.sh#L129-L131 is not needed.
But, you still need to pass the kubelet certificate to metrics-server.

[avoidik]

But, you still need to pass the kubelet certificate to metrics-server.

which is only possible by using some kind of workaround, because kubelet (re)generated certificates will have 0600 permissions on files (so that only the user running kubelet daemon will be able to access them), what do you think?

https://github.com/kubernetes/kubernetes/blob/v1.23.1/staging/src/k8s.io/client-go/util/certificate/certificate_store.go#L196