KHV002 - proposed solution too invasive

[MarkusTeufelberger]

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]

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

[itaysk]

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]

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.

[ledroide]

Hello,

Here is my workaround :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: system:public-info-viewer
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
rules:
  - nonResourceURLs:
      - /healthz
      - /livez
      - /readyz
    verbs:
      - get

What I cannot solve, unfortunately, is that upgrades - I use kubespray for my clusters - overwrites this ClusterRole, and I couldn't find out where to set this sustainably.

That said, I apply my patch every time I run kubespray, and "/version" path is not publicly available.