search

aquasecurity / kube-hunter

Hunt for security weaknesses in Kubernetes clusters
Apache License 2.0
4.7k stars 581 forks source link

KHV002 - proposed solution too invasive #375

Open MarkusTeufelberger opened 3 years ago

MarkusTeufelberger commented 3 years ago

What happened

After getting the error mentioned in the title, I looked into how to fix it and the solution proposed at the moment (completely disable the debugging handlers) seems too far reaching.

Expected behavior

A solution as in https://github.com/kubernetes/kubernetes/issues/84040#issuecomment-585915168 is documented as a solution instead, which only disables this single endpoint for unauthenticated access. Even disabling anonymous authentication would be better than completely disabling debugging handlers (but could lead to issues if load balancers are involved).

avats-dev commented 3 years ago

@MarkusTeufelberger How can this be resolved? I want to work on this. Thanks.

itaysk commented 3 years ago

Thanks @MarkusTeufelberger for reporting this.

  1. I think we need to reconsider this "vulnerability". if KH is running outside the cluster then this is indeed an "information disclosure" issue, but if KH is running as pod maybe it's not an issue. We are still thinking about it (and appreciate any thoughts)
  2. In the meantime, I'm happy to look at PRs for improving the documentation with information from that linked thread (@avats-dev).
MarkusTeufelberger commented 3 years ago

The resolution would likely entail the one outlined in that thread (removing the version endpoint from the list of publicly viewable ones), not disabling a whole API.

I'd expect this solution (and its caveats) to be documented, not the one that disables the debugging handlers (which is also not documented too well, I'd expect for example a way to set this in kubeadm and a discussion of what else will be disabled, not just a simple "Add this flag to kubelet" without any more background info given).

Edit: In my case it was visible from the outside, so it definitely was a (small) information disclosure besides just kubernetes existing on a host (the other 3 public endpoints can't be just disabled, as you can see in the linked thread). I also wouldn't view this as a vulnerability if any pod in the cluster can query this endpoint, since it might be necessary for some decisions to have this information available and there might be more sophisticated ways for an attacker to know the exact version used anyways.