Use Gitpod without OAuth repo access

[florisvdg]

Is your feature request related to a problem? Please describe

To use Gitpod, I currently have to give Gitpod pull and push access to my GitHub account. This makes sense, because Gitpod needs to clone my private repo, and when I make changes, I should be able to push those changes from within my Gitpod workspace.

This may seem inevitable, but there actually could be a way to lift this requirement: SSH agent forwarding (#6993).

In theory, this could replace the OAuth flows to get repo access, so would remove the need for Gitpod to persist Git secrets for pulling and pushing.

Describe the behaviour you'd like

I'd like for Gitpod's access to GitHub repos to go through my SSH agent first, and only exist for as long my SSH session is active. If I close my SSH session, all access to my GitHub repo is gone.

Example: setting up a new Gitpod workspace

Here's what that could look like using VS Code on my desktop:

1. Use a command-palette action to launch a new, empty workspace. In the background, this automatically SSH'es into the empty workspace, but using the -A flag.
2. A VS Code prompt shows up where I can paste in my repo URL (this could be GitHub, but doesn't have to be, that's the beauty of SSH authentication).
3. Gitpod clones the repo, which it can do because of the -A flag. The authentication goes through my local SSH agent.
4. I do some coding, a few pulls and pushes, and then close my VS Code window (and therefore also the SSH session to Gitpod).
5. Gitpod has no access to my Git remotes anymore.

Describe alternatives you've considered

I'm less concerned about read access than write access, so an OAuth flow with read-only access would also suffice. However, the GitHub OAuth scope for repos combines read+write access, so that won't work.

For public repos, this would be an option though. Gitpod could clone from the browser, I'd make some edits, and when I'm ready to push, I SSH into Gitpod with -A, run git push and be done.

[loujaybee]

Thanks for raising @florisvdg

It's an interesting proposition that I'd need to experiment with. It brings some benefits (potentially) but also some downsides, e.g. because many customers use Gitpod so that source code never hits the users machine, whereas this would introduce an alternative paradigm where the local machine is assumed trustworthy, and the remote is not.

Some initial thoughts: There is auth for Gitpod, and auth for repo's, worth mentioning that we'd still need some auth for users, even if that doesn't involve repo or code access (unless you were self-hosting and chose not to use auth and only network, or something else. I am not sure how easy hard dropping auth would be in a self-hosted context).

To implement this would rely on us having workspaces without VCS (e.g. blank - #7722), but workspaces and repo's are currently 1<>1. Or... a workaround could be to simply link an irrelevant or blank repo. One additional challenge is how those files get mounted into the workspace, and then subsequently removed.

If you want, you could experiment with:

• [ws-proxy] SSH gateway support full channel type #10291
• SSH Gateway doesn't support remote port-forward #10248

And...

• https://www.gitpod.io/docs/ides-and-editors/command-line
• https://www.gitpod.io/changelog/ssh-directly-into-workspaces

To see if you could get this working as a PoC.

[florisvdg]

Thanks for your response!

some downsides, e.g. because many customers use Gitpod so that source code never hits the users machine, whereas this would introduce an alternative paradigm

To clarify (just in case): In my proposal, the Gitpod workspace will still be the one doing the cloning work, file hosting work, etc. My local machine would not store any source code. So no changes there.

So in terms of responsibilities:

My local workstation:

• Running VS Code with Remote Development linked to a Gitpod workspace
• Authenticating SSH requests (through agent forwarding)

The remote Gitpod workspace:

• Cloning, pulling, pushing, etc.
• Storing the cloned repo
• Running tests, launching debug builds, offering terminals, etc.
• Serving SSH

worth mentioning that we'd still need some auth for users, even if that doesn't involve repo or code access

"Metadata" auth is fine, as long as there are no long-lived secrets for pulling and pushing kept around.

To implement this would rely on us having workspaces without VCS (e.g. blank - #7722), but workspaces and repo's are currently 1<>1.

Yep, that would be nice, so that private repos can be supported too. However, for public repos, this 1:1 link is actually not a problem. In fact, it's nice that you can already initialize the repo from the browser and do some initial coding work. And then only when/if you're ready to push, you'd ssh -A into the workspace.

Once the agent forwarding fix (#6993) has been deployed, I can try and see what happens if I uncheck the repo permissions and then ssh -A into my workspace.

Ideally, ssh -> git pull would then fail due to being unauthenticated, but ssh -A -> git pull would succeed.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[florisvdg]

Bonus: promoting this workflow would also bring in commit signing for free! (though GitHub only for now) https://github.blog/changelog/2022-08-23-ssh-commit-verification-now-supported/

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.