### Background Current workspaces setup requires users to 1. Create a Kubernetes cluster 2. Connect the Kubernetes cluster with GitLab by installing the GitLab Agent for Kubernetes 3. Authorize the GitLab Agent for Kubernetes in GitLab 4. Buy a new domain or use an existing one 5. Generate TLS certificates for 2 subdomains 6. Ensure the TLS certificates are renewed at regular intervals 7. Register an OAuth application in GitLab 8. Generating an SSH host key 9. Install GitLab Workspaces Proxy with all the above steps 3 to 7 configured In https://gitlab.com/gitlab-org/gitlab/-/issues/505764+ , `@DylanGriffith` showcased a PoC on running Workspaces through a CI job ([video demo](https://www.youtube.com/watch?v=TVGkBn726Bk)). Through this investigation, 2 architecture design documents were merged - - https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/reverse-grpc-tunnel-workspaces-and-ci/ - https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/deploy-workspaces-with-ci-runner/ This epic aims to take forward the former architecture design document as an independent form of work regardless of how we decide on the latter architecture design document. ### Description In the above list, step 1 is required for the underlying infrastructure, step 2 is required to connect that infrastructure with GitLab and step 3 is required to authorize which projects can use this infrastructure. Everything from step 4 and beyond can be simplified from a user perspective by removing it. Each of the above step can go wrong in multiple ways and thus completely eliminating them is something we should aim for as it would reduce the setup error scenarios. The primary purpose of GitLab Workspaces Proxy is to have a centralized location in the user's Kubernetes cluster to authenticate and authorize the traffic incoming to any/all workspaces in that Kubernetes cluster which was done in https://gitlab.com/groups/gitlab-org/-/epics/9940+ . With the change proposed in this epic, the existing architecture stays as is except for the fact that we will no longer need GitLab Workspaces Proxy and the Ingress Controller in the architecture. This will eliminate the most challenging part of setting up workspaces. Users will no longer need to buy/manage domains or the TLS certificates for them. This will be achieved by moving the logic of proxying traffic into the right workspace outside of GitLab Workspaces Proxy in user's Kubernetes cluster to a server hosted and managed by GitLab as part of GitLab Agent Server(KAS). What this translates into is as follows in terms of technical work - - Add support for [Reverse gRPC tunnel for GitLab VS Code fork in Workspaces](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/reverse-grpc-tunnel-workspaces-and-ci/) - Co-ordinate with infrastructure to configure the necessary domains/URLs to this new server which will reverse tunnel as mentioned above. - Inject required components into each new workspace to eliminate the need for GitLab Workspaces Proxy. For the purposes of transitioning users, we will first make this opt-in which is the scope of this epic. Then follow it up with work to make this approach the default and then remove GitLab Workspaces Proxy altogether will not be in scope of this epic. ### Expected Outcomes - Reduce user requirements to setup Workspaces by eliminating unnecessary steps. - Eliminate all the error scenarios that could originate from not removing these steps. - Eliminate the need for GitLab Workspaces Proxy in the current Kubernetes setup thus reducing setup complexity and requirements. - Lay the ground work for being able to run Workspaces on non-Kubernetes infrastructure - https://gitlab.com/groups/gitlab-org/-/epics/16650+ ### Note This epic was earlier part of https://gitlab.com/groups/gitlab-org/-/epics/16650+ and was later moved out of it because this work is independent of whether or not we decide to move to CI Runners. This work has value in itself to be pursued separately. All the architecture discussions are part of https://gitlab.com/gitlab-org/gitlab/-/issues/519307+