Remote tunnels for all users in a GitHub organization

[staticfloat]

Hello, congratulations on the launch of remote tunnels; they're awesome!

I would very much like to use tunnels that are shared within a GitHub organization. Is there any way I can grant access to a vscode remote tunnel? I'm thinking something like code tunnel --grant-github-org=org-name --accept-server-license-terms or similar. This would be very useful for automated debugging, as we can embed this within our CI pipelines to provide an interactive debugging experience when a job fails.

[OneCyrus]

that would be nice. also limiting to a GitHub team would be a great addition to this request.

[connor4312]

This is a lot of work, since the VS Code server itself doesn't really support multiple users, and you run into permissions problems. The CLI could spawn sessions into different users, if running on posix and as a super user, though this is not something we know anything about today. We'd additionally need to actually manage ACL's for dev tunnels, which we also do not yet deal with.

[simonbyrne]

This is a lot of work, since the VS Code server itself doesn't really support multiple users, and you run into permissions problems. The CLI could spawn sessions into different users, if running on posix and as a super user, though this is not something we know anything about today. We'd additionally need to actually manage ACL's for dev tunnels, which we also do not yet deal with.

I don't think that is quite what @staticfloat had in mind: I think he wants to run the code CLI as the current system user (which would typically be some sort of container default user), and print the access code to the CI log. However the log will be publicly accessible, so he only wants certain GitHub accounts to be allowed to enter that code and link the tunnel with their GitHub account.

[connor4312]

That experience would be possible with just the "ACL" part of the changes I mentioned, which is a good stepping stone. Just from reading the docs, it looks like azure Dev Tunnels may already support this.

However, I'm not sure this is something we'd release, since VS Code is still not made to share multiple users in single instance. For example, VS Code provides APIs for extensions to store secrets, and that's how authentication extensions store their credentials. It's not obvious (by design!) where an extension is running, and if an authentication extension is running on the remote and a user logs in to an account, they unintentionally grant that access to all other users who have access to the tunnel.

We've thrown around the idea of "untrusted remotes", similar to how workspace trust works. That may be prerequisite. Will discuss with the team this week. @TylerLeonhardt has also asked for a very similar scenario.

[connor4312]

One solution I thought of to avoid the scary mutli-tenancy situation was 'locking' the shared tunnels to the first user who connects to it; other users would then get some error message if they try to connect. The originating user could still use Liveshare if they needed wanted to collaborate with others in that session.

I believe this may be the cleanest path to solving your pipeline use case, what do you think?

[simonbyrne]

Yes, that would make the most sense I think

[staticfloat]

Yes, that sounds great to me!

[arc-hbas]

I would also like to see another CLI option to limit access to any account under the specified org (and only the first one to connect as described above). Similar to OP but slightly diff: code tunnel --limit-github-org=org-name --accept-server-license-terms