[Spike] Shared workspaces

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Description

There's some use cases where it'd be nice for different GitLab users to seamlessly connect to the same workspace. This brings up a lot of architectural considerations:

• How do we represent that a workspace is owned by a "Project" (or a system user of the "Project") and available to a subset of users (possible based on access level).
• How do we dynamically provision and secure multiple users within the running container?

Considerations / Questions

...

Spike Objectives

...

Future Tasks

...

Context

• Context: “Think Big” idea “What if we had Review Workspace vs. Review Apps for Merge Requests”? This implies a “shared” workspace where multiple users can hop on.

  • A “shared” workspace implies that we need the user connected in the workspace (i.e. whoami) to represent the GitLab user (not necessarily the user that created/”owns” the workspace).
  • We can’t necessarily know the possible set of users ahead of time, so this implies the need for us to do a useradd on the workspace to provision a secure sandbox for that specific user in the workspace.
  • For us to dynamically provision container users, we’ll need to run commands in an existing workspace, triggered by the Rails app whenever the user is requesting to connect…
  • brainstorm: For us to run commands in the existing workspace, what if we had a CLI tool that could be included in every workspace? Rails could execute this CLI tool through ssh as the system user that owned the workspace.

• Notes from sync discussion document (internal): https://docs.google.com/document/d/1C4iOFmNDTQV--kbO9RPPwdd2fwyleiE-H1XGjwNWIEM/edit#heading=h.6v0tbiqtovs5