[pve-devel] [RFC firewall/proxmox{-ve-rs, -firewall, -perl-rs} 00/21] autogenerate ipsets for sdn objects

Thomas Lamprecht t.lamprecht at proxmox.com
Tue Sep 24 10:41:07 CEST 2024


Am 26/06/2024 um 14:15 schrieb Stefan Hanreich:
> The current series generates all those ipsets in the datacenter scope. My
> initial approach was to introduce an separate scope (sdn/), but I changed my
> mind during the development because that would require non-trivial changes in
> pve-firewall, which is something I wanted to avoid. With this approach we just
> pass a flag to the cluster config loading wherever we need the SDN config - we
> get everything else (rule validation, API output, rule generation) for 'free'
> basically.
> 
> Otherwise, the other way I see would need to introduce a completely new
> parameter into all function calls, or at least a new key in the dc config. All
> call sites would need privileges, due to the IPAM being in /etc/pve/priv. We
> would need to parse the SDN configuration everywhere we need the cluster
> configuration, since otherwise we wouldn't be able to parse / validate the
> cluster configuration and then generate rules.
> 
> I'm still unsure whether the upside of having a separate scope is worth the
> effort, so any input w.r.t this topic is much appreciated. Introducing a new
> scope and then adapting the firewall is something I wanted to get some feedback
> on before diving into it, which is why I've refrained from doing it for now.

I'd prefer a separate scope to avoid potential clashes of IDs on upgrade and
to continue with the scope split we did for cluster-level ("dc" scope) and virtual
guest-level ("guest" scope) IPsets back from PVE 7 to 8, so while one _might_
see the SDN ones as fitting into the "dc" scope, a separate SDN scope is IMO
a bit nicer w.r.t. separating the origin.

I'd be good to know what the problems where when introducing that new sdn scope,
maybe there's a simpler workaround/design.




More information about the pve-devel mailing list