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 Is there any planned feature for creating additional non admin end users with access to an individual incusOS machine or to a cluster? Will Operations Center be required for making additional users? Would end user access be through sso, credentials, or certs to access certain parts of the webgui? ie delegating restricted access to less tech savvy users to an isolated project or area in cluster or certain IncusOS node for certain end users to be able to do some click-ops to access, create, manage their own vms or containers?

Merci

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