Networking questions securing locking down IncusOS, WAN clustering, and granting user access

[chrislawso]

I recently discovered IncusOS was released. Very impressive progress by developers and Zabbly!

Completed successful IncusOS install, completed the cli tool and web browser cert setup etc, able to connect to IncusOS with cli tool and with web browser to access the Incus UI management web gui. Was following the instructions at Accessing the system - IncusOS documentation

I’m confused why does the IncusOS network interface at ip.ip.ip.ip:8443 continue forwarding to and displaying https://ip.ip.ip.ip:8443/ui/login/certificate-generate which appears to allow any unauthorized users to continue to generate create new certificate? What are next steps to limit insecure exposure?

I found somewhat related topics at

Extend network API to support basic input firewalling

Firewalling in IncusOS

I’ve filed Extend network API to support basic input firewalling · Issue #528 · lxc/incus-os · GitHub to track adding of basic input firewall rules to IncusOS. We’re most likely to do this directly through nft. The ufw syntax is convenient but it’s a python script and we’re trying pretty hard to keep the base image as small as possible. So far we’ve managed to keep it to basically just shell scripts and binary stuff. No python in there and we’ve stripped most of the perl stuff. I also don’t k…

For IncusOS on machines with only a single public WAN fully exposed nic, what is best recommended practice? Setup netbird or headscale, then change the Incus service ip.ip.ip.ip:8443 to a different local only network bridge that only allows connections from netbird or headscale? Or per above link could firewall be setup to deny all first then whitelist certain ips to :8443 ? Are there any alternative best practice methods for securing public facing IncusOS?

What are latency thresholds that will cause issues maintaining WAN Clustering or are there hard limits that will cause cluster manager or cluster database node failures due to lossy stretched network?

What would be ideal deployment scenario of IncusOS onto a few different VPS virtual machines at different providers on disparate ip address networks, where each IncusOS instance gets single public wan ipv4?

For production use appears load balancer recommended to pool all cluster ips, can HAProxy be used as externals load balancer for all IncusOS nodes or what are recommended light weight load balancer to pool cluster ips? Was reading Creating an Incus cluster - IncusOS documentation and didn’t see any pages mentioning load balancer. What are other important considerations to plan for?

Lastly, curious after reading and watching Operations Center - IncusOS documentation https://youtu.be/TzH2L5Bzlh8?t=2997 and I read at Offer a full Incus deployment as part of Incus initialization · Issue #497 · lxc/incus-os · GitHub about plans for IncusOS development work for SSO, openFGA, etc. I recognize requires work on several moving parts. Is the long term plan that any multi user role base access control will require clustering and the whole application suite running together ie cluster, oidc, openfga etc in order to setup authentication and authorization access for additional user management?

Or will a single IncusOS instance , non-clustered, have or not have capability of creating and defining additional non-admin certificate users with restricted access to project or some restricted space in single IncusOS? ie any possibility that in future a single IncusOS instance can run a minimal application stack ie operations-center with OpenFGA and admin can bootstrap some config files or whatever required to support basic level authentication and authorization to single node IncusOS without clustering? Create OpenFGA application · Issue #354 · lxc/incus-os · GitHub

[moonpiedumplings]

@chrislawso

which appears to allow any unauthorized users to continue to generate create new certificate? What are next steps to limit insecure exposure?

This is a non issue. Users don’t just need to generate a certificate, but also to import it to the system, which requires admin privileges to do so. If they don’t have access to the system, they can’t import their certificate.

[chrislawso]

OK. So only the admin with the cli tool that’s been cert paired to incusOS is only one with privilege to perform adding more client certs and the following operation sends it to IncusOS:

2.Trust

Download the .crt file and add it to the Incus trust store
incus config trust add-certificate Downloads/incus-ui.crt

Sorry I got confused testing certs with a few different browsers, some browser applications after changing or removing all certs and closing all windows to restart they would still be able to open the admin incus web UI which was confusing ie wtf was happening, led me to believe maybe the incus UI was automatically saving certs to the IncusOS server.

Later I realized the browser would remain running as background process and never actually restarted and was magically retaining certs that were removed from security cert manager. Needed to check process list and kill all running browser to make certain process actually completely dead in order to force reset browser certs.