bind to unix domain socket #144
Comments
|
@jeanp413 It should be also alright we remote CLI? And the browser will connect to it via special proxy configured on the same machine correct? It would be good if someone could write a guideline for such approach. |
|
Can this also be solved via K8s network policies? (TCP firewall) |
|
@akosyakov I'm not sure I understand your question. The reverse proxy architecture is where you run the server you want to protect in a mode where it's listening for connections from a limited set of sources, and then one of those sources is the reverse proxy, which it trusts to do authentication and authorization. The browser can then be anywhere that can reach the reverse proxy. The only change I'm proposing here is to further restrict the sources the server is listening on, shrinking it from "anyone with access to localhost" to "only the current user on localhost". |
|
@elgalu if you're in kubernetes, that's a completely reasonable way to establish a similar level of security. Only people who can exec into your pod would be able to bypass the proxy and connect without auth. |
|
@leifwalsh I think you can do ahead and suggest the PR. |
This adds a CLI argument --socket, that takes a path. The server will bind this path instead of a TCP port. closes gitpod-io#144
This adds a CLI argument --socket, that takes a path. The server will bind this path instead of a TCP port. closes gitpod-io#144
This adds a CLI argument --socket, that takes a path. The server will bind this path instead of a TCP port. closes gitpod-io#144
|
There you go! |
This adds a CLI argument --socket, that takes a path. The server will bind this path instead of a TCP port. closes gitpod-io#144
This adds a CLI argument --socket, that takes a path. The server will bind this path instead of a TCP port. closes #144
This adds a CLI argument --socket, that takes a path. The server will bind this path instead of a TCP port. closes #144
This adds a CLI argument --socket, that takes a path. The server will bind this path instead of a TCP port. closes #144
This adds a CLI argument --socket, that takes a path. The server will bind this path instead of a TCP port. closes #144
This adds a CLI argument --socket, that takes a path. The server will bind this path instead of a TCP port. closes #144
This adds a CLI argument --socket, that takes a path. The server will bind this path instead of a TCP port. closes #144
This adds a CLI argument --socket, that takes a path. The server will bind this path instead of a TCP port. closes #144
This adds a CLI argument --socket, that takes a path. The server will bind this path instead of a TCP port. closes #144
This adds a CLI argument --socket, that takes a path. The server will bind this path instead of a TCP port. closes #144
This adds a CLI argument --socket, that takes a path. The server will bind this path instead of a TCP port. closes #144
Some people in other issues and discussions have asked for better security and it's been suggested to run openvscode-server behind a reverse proxy like NGINX. That works well if you can bind only to localhost or use firewall rules to prevent outsiders from bypassing the proxy, but doesn't help if you're on a shared machine that many people can SSH to.
For this case, it would help if there were an option (e.g.
./server.sh --socket /tmp/leif-openvscode-server.sock) to listen on a UNIX domain socket instead of a TCP port. This way, we could use file permissions to make sure no other users on the machine can connect to that socket, and I could run openvscode-server and my proxy as the same user, ensuring that the only way in is through the proxy.I believe this change is simple: just add an option to the server and call this variant of
http.Server.listen()that accepts a path: https://nodejs.org/api/net.html#net_server_listen_path_backlog_callbackThe text was updated successfully, but these errors were encountered: