Epic: Restrict access to snapshot URLs

[jldec]

Gitpod snapshot URLs, provide a way to share a snapshot of a workspace e.g. for easy reproduction of test environments.

For workspaces of private git repos, these URLs could be used to access sensitive or proprietary files.

• Run the "Gitpod Share Workspace Snapshot" command in a workspace, to receive a new snapshot URL.
• Any Gitpod user could use this URL to open a new workspace with the same state.

The proposed fix is to limit access to the workspaces from snapshot URLs to those users who have read access to the repo.

1. Determine the git remote for the snapshot
2. Ensure that the user opening the workspace with the snaphot URL has read access to the git remote.
3. If not, show the error from the git provider, and a suggest requesting access to the repo (see below).

Since this changes the behavior of existing snapshot URLs, the error should also include the following explanation

Snapshot URLs require read access to the underlying repository.
Please request access from the repository owner.

NOTE: Breaking change
This change may break some usage scenerios where private repo workspaces are intentionally shared via snapshots e.g. for interviews.

• https://github.com/gitpod-io/website/issues/1625
• https://github.com/gitpod-io/website/issues/1624
• Track snapshot usage with success and access-error events #8340

[jankeromnes]

Happy to give this a go tomorrow

/assign

[gtsiolis]

This could also apply to running workspaces as well as snapshots, see #4841.

See also #4841 (comment).

Also, maybe it could be worth considering to share only with team members by default and allow users to manually switch to share with anyone with a link. 💡

[csweichel]

This could also apply to running workspaces as well as snapshots, see #4841.

Running workspace access is mediated by ws-proxy, who has no notion of the authentication on server side. We'd need to introduce guest tokens (which we conceived of when we introduced the owner token, hence the name).

[chuck-confluent]

whoa whoa whoa...a workspace snapshot may have sensitive credentials in files ignored by git. The owner of the workspace should reserve the right to limit access to the snapshot URL or revoke the URL at any time, regardless of what repo permissions people have.

[chuck-confluent]

If someone accidentally creates a snapshot URL instead of sharing a running workspace, is that snapshot url public and available at all times? You can kill a shared running workspace, but can you manage access or kill a snapshot? I'm looking at https://www.gitpod.io/docs/sharing-and-collaboration#how-to-take-a-snapshot-url and it only describes how to create the snapshot url. It does not mention about revoking or managing access to the snapshot url.