Description
While we do handle errors pretty well in many cases, there is work to be done.
Currently we have manually synced our types from k8s API docs. However, we don't check that the responses are valid responses.
- What happens if there's a change in API in newer k8s versions we don't check?
- What about a malicious k8s API controlled by someone else, which can then be used to attach to other clusters or run local commands?
We already have one bug about a feature broken with a new k8s release (and have had others in the past)
We already have one bug report about showing errors better:
However there are many cases where we just do a console.error and that's it. Many of the error conditions are not tested in the frontend either. Much of our test coverage in the frontend is only happy path stories. Much of our k8s API is not tested thoroughly. For example cluster.ts and hooks.ts lack unit tests. The e2e tests we have do no cover error conditions at all.
Additionally the k8s API does not work very with the typechecker currently. There is work ongoing for a while to address this, and that is covered in separate issues. I mention this here because lack of type coverage increases the risk as well. Even when we do have good type coverage we still need to parse/validate the API responses. Because bad actors could influence the k8s API response by injecting data in there from many different places. Less of a risk (but still a risk) is that a bad actor controlling a k8s API server can then jump to execute commands or control other k8s servers they are not authorized to control (Iff Headlamp has issues that can be exploited).