Open MarkusTeufelberger opened 3 years ago
@MarkusTeufelberger How can this be resolved? I want to work on this. Thanks.
Thanks @MarkusTeufelberger for reporting this.
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.
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).