vscode-dev-containers
vscode-dev-containers copied to clipboard
microsoft
Use guacamole instead of noVNC in desktop-lite-debian
Right now the desktop-lite-debian feature uses the noVNC to allow access from a browser. However, noVNC uses WebSockets to actually connect using insecure VNC protocol, which, if I am not mistaken, basically limits this functionality to containers running locally, leaving Codespaces out.
Instead, use guacd + guacamole client[^1] (both locally inside the container) to allow connecting with a browser using a regular HTTPS. On top of the obvious benefits, the guacamole protocol they use should be better optimized for such use case. https://guacamole.apache.org/doc/gug/guacamole-architecture.html for more details.
Looking at the desktop-lite-debian.sh code, this should be a fairly straightforward, in-place substitution.
Relates to: Codespaces & Remote - Containers
[^1]: MySQL/Postgree are not required, user-mapping.xml file is enough: https://guacamole.apache.org/doc/gug/configuring-guacamole.html#basic-auth
Some good news - this is already intended for use in Codespaces thanks to how the service (and Remote - Containers) work.
Port forwarding in Remote - Containers and Codespaces is done over the same channel that is used to communicate with the remote host. If you are using a remote docker host with Remote - Containers, generally I'd recommend using SSH (DOCKER_HOST=ssh://).
Port forwarding in Codespaces uses authenticated https requests on the web and a secure point-to-point, encrypted tunneled connection for local. In the local case, it's only the last mile from your browser to localhost that is not encrypted. (Note that, on the web, ports are not available publicly at all by default either.)
Straight Docker port publishing (e.g. -p) is not used since this would also make exposing your web application or other forwarded services insecure. In Codespaces, if you try to publish a port, it won't be accessible for that reason. You need to use port forwarding instead (forwardPorts in devcontainer.json or automated forwarding).
Also note that the actual VNC port (5901) does not need to be exposed for novNC to work. The VNC port is something you can optionally expose if you prefer to use a VNC viewer, but otherwise actual VNC connectivity is all local to the container.
Certainly guacamole is an option, but I'm not sure what this would add on top of what is already in place. We'd have to take a look at the impact of that change. I think the concern I have looking at it is it seems to need a servlet container which will drag quite a few dependencies beyond what we're already including.
