Hello friends.
As it stands it is possible for any user to accidentally cause a denial of service by creating a network forward on the same port / ip as the main incus api ip / port.
This then prevents further api access to Incus.
Suggesting that a filter is placed so that forward sources cant be applied to the main API ip and port.
What do you think?
The two ways to cause this kind of issue are either with a proxy device or a network forward, both using the host address. Neither of those are normally allowed in a restricted environment, so this is only possible for a user with global access to Incus at which point they have many other ways to cause a similar DoS.
Trying to restrict the host IP from being used for forwards or proxies wouldn’t really work as many standalone Incus users actively rely on this being something they can do.
Restricting the IP+PORT combination would be less likely to cause regressions, but that’s still pretty tricky as most of the time, a specific IP isn’t selected, instead Incus typically listens on all IPs. We’d also get into some more complex situations when it comes to validation, for example having to now check all changes to core.https_address against all existing forwards and proxies.
Overall, this doesn’t really seem worthwhile when multi-tenant environments already have the required restrictions in place to prevent this kind of thing.
That makes sense, I will look into the multi tenant setup you have mentioned and utilise that. thanks Stephane.