Kasm - Virtual Desktop / Browser Isolation
-
@plusone-nick What type of infrastructure you have? On site or in cloud?
-
@DualOSWinWiz both
@plusone-nick do you a repo for Kam on Cloudron that you can share ?
-
@plusone-nick do you a repo for Kam on Cloudron that you can share ?
@timconsidine nope sorry never dug into it too much
-
@savity As much as i would love to see this or even something similar on Cloudron I don't believe there is any current development happening so i would not get hopes up. Going to have to find another implementation solution for this ONE for now...
-
I use Kasm and I like it, but I would describe it as a “slippery slope”.
It can be a resource hog if you have multiple workspaces running. Maybe if it’s just one solo user running only one workspace at a time, it’s viable from resources point of view on a Cloudron host.
But if you have one user running multiple workspaces or multiple users, it quickly merits being on its own VPS (which is how I have deployed it).
So yes, concept Kasm on Cloudron is appealing, in practice better to deploy separately, so packaging work for Cloudron maybe not realistic application of effort. -
Yes, I would see the resource usage as a critical topic here. I think it is easier to run https://forum.cloudron.io/topic/7380/webtop-dockerised-linux-desktop-in-a-browser?_=1718484389586 in a container and then add cloudron proxy auth infront of it. webtop uses the same project (kasmvnc) for the rendering in the browser. this is then essentially single user, but you can repeat the container part multiple times for different users.
-
BTW I have built something similar with Apache Guacamole (on the app store) and a local Ubuntu XFCE Docker. Although not recommended, if you configure the network for such Docker correctly, you should have no interference with Cloudron.
If anyone is interested, I can put up a guide (and if staff doesn’t disagree) -
@robi said in Kasm - Virtual Desktop / Browser Isolation:
I would start with the outer part, which means helping the Cloudron team integrate Sysbox.
It would require a new base container image that runs with a new container runtime (sysbox) instead of the default. This is just an extra parameter in the docker run command.
$ docker run --runtime=sysbox-runc -it some-imageAll else stays the same.
In this container, you can now run Systemd, Docker, Kubernetes, etc., just like you would on a physical host or virtual machine. You can launch inner containers (and even inner privileged containers), knowing that the outer container is strongly isolated from the underlying host (via the Linux user-namespace). No more complex docker images or docker run commands, and no need for unsecure privileged containers.
Thanks. Would this container need any modifications to enable it to run init daemons, like OpenRC, Dinit, s6, runit, SysVinit, and Upstart?
@LoudLemur said in Kasm - Virtual Desktop / Browser Isolation:
@robi said in Kasm - Virtual Desktop / Browser Isolation:
...
Thanks. Would this container need any modifications to enable it to run init daemons, like OpenRC, Dinit, s6, runit, SysVinit, and Upstart?No, other than installing the init services. That's why it's a new, different or user supplied (docker) base image that already has these installed.
Very flexible once you escape the regular docker runc limitations.
You can run an entirely different distro if you want to.
