### Proposal Build on the technical foundation of the [CI tunnel](https://gitlab.com/groups/gitlab-org/-/epics/5781) to enable Kubernetes API access directly from the GitLab frontend. ### Motivation This would remove the need for building out bespoke endpoints in the GitLab rails backend or KAS for features that really only require K8S API access, enabling very rapid iteration on the frontend. ### Use cases - An obvious example is the [resource dashboard](https://gitlab.com/groups/gitlab-org/-/epics/2493) - This could also be used to enhance existing features, such as [Deploy Boards](https://docs.gitlab.com/ee/user/project/deploy_boards.html#deploy-boards) without reactive caching, and more reliable [Pod terminals](https://docs.gitlab.com/ee/user/project/clusters/deploy_to_cluster.html#web-terminals-for-kubernetes-clusters) - Something more far out, but possibly exciting, like [a webassembly.sh terminal](https://github.com/wasmerio/webassembly.sh) with built-in `kubectl` (compiled to wasm) ### Security Roughly the same as for the CI tunnel, but with the frontend replacing the role of the runner. The frontend obtains a token (or cookie) that it can use to call KAS, and KAS uses the token to route the request to the cluster. Like the CI tunnel, there would be two tiers of authorization: - GitLab-rails controls who can obtain a token - In-cluster RBAC based on the identity reported by KAS This should be an **optional** function, i.e. it should be possible to disable.