Feedback: Improve GitLab Workspaces SSH access
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Proposal
GitLab Workspaces currently supports remote SSH access to a workspace. The primary use I (and my users) see for this is so that they can use VSCode on their Windows laptop, but have access to an environment running Linux (the workspace). Users prefer the permanence, customisation and performance of native VSCode over the browser version in Workspaces.
Currently, the workflow looks like this:
- Provision a Workspace via the GitLab UI
- Connect to the Workspace using the "Remote - SSH" VSCode extension
- Enter the Personal Access Token (PAT). Enter it again when VSCode prompts for it a 2nd time (not sure why)
- Clone the project of interest to the Workspace
- Open the project in VSCode
- Enter the Personal Access Token (PAT). Enter it again when VSCode prompts for it a 2nd time (not sure why)
- Do development
As a user I've been having to keep a Notepad document with my PAT on hand so that I can enter it as VSCode prompts for it anytime a new project is opened, and sometimes randomly. It's very annoying and obviously a security issue waiting to happen.
If GitLab Workspaces switched to public-key SSH authentication, the workflow could instead be:
- Provision a Workspace via the GitLab UI
- Connect to the Workspace using the "Remote - SSH" VSCode extension
- Clone the project of interest to the Workspace
- Open the project in VSCode
- Do development
Technical implementation
Currently the gitlab-workspaces-proxy uses the user-self-lookup API to figure out the ID of the calling user so that it can do the basic "are you allowed to access this specific workspace" check.
Instead, the proxy could use an API like the "Get user by fingerprint of SSH key" API to figure out the ID of the calling user based off of the public key that they present. This endpoint is only available to administrators, but hopefully it gets the point across.