Kasm - Virtual Desktop / Browser Isolation
-
Yes its a good application but very resource intensive workspace so i hosted it separately but their was a proxy issue and was not working so for the timebeing i used nginx proxy manager but @girish released a patch in the last update 7.60. Now all is good and i am using it withing cloudron and also used cloudron ODIC integration it was long weekend night but well spent.
-
Yes its a good application but very resource intensive workspace so i hosted it separately but their was a proxy issue and was not working so for the timebeing i used nginx proxy manager but @girish released a patch in the last update 7.60. Now all is good and i am using it withing cloudron and also used cloudron ODIC integration it was long weekend night but well spent.
@DualOSWinWiz have any specific docs that would save us some time that you could share?
-
@DualOSWinWiz have any specific docs that would save us some time that you could share?
@plusone-nick What type of infrastructure you have? On site or in cloud?
-
@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.
-
I have Kasm running behind a Cloudron reverse proxy and connected to Cloudron's OIDC directory for user authentication. It was pretty straightforward to set up, but if anyone wants/needs a written guide, I am happy to do so.
-
@hakunamatata that will be great. Maybe something for https://docs.cloudron.io/guides/community/ too?
-
@joseph ok will do
-
-
Install Kasm. (I have it running on a dedicated VM and followed the single server installation instructions: https://kasmweb.com/docs/latest/install/single_server_install.html)
-
Once installed, log into the Kasm host using the admin credentials and then configure the reverse proxy by going to Infrastructure > Zones in the left hand side panel and following the instructions here: https://kasmweb.com/docs/latest/how_to/reverse_proxy.html#update-zones
(Note: in my case, the default parameters worked fine) -
Install the Cloudron App proxy and point it to your Kasm host e.g. https://[IP-ADDRESS]:443. Now you should be able to access the Kasm login page via the domain you set in the app proxy. e.g. kasm.yourdomain.tld
-
To use OpenID authentication, first we need to add Kasm as an OIDC client in Cloudron. Go to Cloudron > User Director > OpenID Connect Provider > New Client, and enter the following:
Name: kasm
Login callback URL: https://kasm.yourdomain.tld/api/oidc_callback
Signing Algorithm: RS256
Copy the resulting Client ID and Client Secret for use in step 5.
- Now in Kasm, go to Access Management > Authentication > OpenID and follow the instructions here: https://kasmweb.com/docs/latest/guide/oidc.html
Main parameters to be set are:
Display Name: Can be anything e.g. Login with Cloudron
Hostname: kasm.yourdomain.tld
Client ID: paste from step 4
Client Secret: paste from step 4
Authorization URL: https://my.yourdomain.tld/openid/auth
Token URL: https://my.yourdomain.tld/openid/token
User Info URL: https://my.yourdomain.tld/openid/me
Scope (One Per Line): openid profile email
Username Attribute: sub
Redirect URL: this should be automatically populated and should match what you entered as the callback url in step 4 i.e. https://kasm.yourdomain.tld/api/oidc_callback
I believe that should be it! Give it a shot and let me know if you run into any issues. There could be a possibility that I forgot to document something in the above steps. Once it is confirmed to be working, I will polish it up and submit it as a community guide.
-
