Kasm - Virtual Desktop / Browser Isolation

[plusone-nick]

https://www.kasmweb.com/
https://www.kasmweb.com/kasm_server.html

Leverages Docker for "Streaming isolated remote applications and desktops to the browser"

Key points: Enterprise Features (Community Edition limited to 5 sessions at a time)

• AD / LDAP integration
• SAML Single Sign-on

Seems pretty useful, especially coupled with the rest of Cloudron. Many use cases can be applied here.

They are on 1.7 and appear to be gaining customers - worth keeping an eye on at the least

[murgero]

@plusone-nick Oh imma try and package this right now.

This might be trickier than first expected - the software seems to only have a docker-compose install which I am not 100% sure would translate to cloudron

[robi]

@murgero is that just because of the various other containerized apps (browsers) it pulls in?

that's just extra directives in the Dockerfile no?

[murgero]

@robi No, I can see how it can load desktops and such - it's the way the server backend is installed - using multiple different containers that one app can't use on it's own without Cloudron adding a new "addon"

[robi]

@murgero this sounds like a perfect use case for Sysbox.

That way a full machine image can be installed with Kasm to have access and control over all the containers.

Docker in docker, the outer one managed by Cloudron, the inner one by Kasm.

[murgero]

@robi Kasm already supports full desktops in docker - or it at least gives the illusion of it.

[robi]

@murgero I am aware hence my comment.

if you want to split the bounty on this one, I'll help with Sysbox.

[murgero]

@robi I'd love to - I just don't know where to start tbh

[robi]

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-image

All 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.

[murgero]

@robi It would be more ideal to get the Kasm devs to also give a build not reliant on docker - so we can dockerize it ourselfs, or at least I would think that way anyway.

Sysbox is pretty cool but I'm sure that would require a complete overhaul of current code?

[robi]

I am going to disagree here. The docker solution is elegant and doesn't pollute the filesystem with lots of X libraries and other junk.

In fact the sysbox-runc is more secure than the current one, hence if Cloudron decided to use it, all it would take is a one parameter addition.

--runtime=sysbox-runc

no overhaul required.

[murgero]

@robi Oh wow - if that's the case then it definitely is at least worth more research and discussion.

[robi]

@murgero

[RazielKanos]

any news on this, I just watched a tutorial video on KASM and it really looks very interesting

[timconsidine]

@RazielKanos yep, it's nice.
I have KASM on a separate VPS and it's useful.
In my case, I don't use KASM enough to justify it using a whole VPS.
So it would sure be good to have it in Cloudron as an occasional resource, and get rid of the other VPS.

[LoudLemur]

@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-image

All 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?