[pve-devel] [PATCH pve-access-control v2 1/1] permissions: add ACL paths for SDN fabrics

[Fabian Grünbichler]

> Stefan Hanreich <s.hanreich at proxmox.com> hat am 07.04.2025 10:51 CEST geschrieben:
> 
>  
> On 4/7/25 10:12, Thomas Lamprecht wrote:
> > Am 07.04.25 um 09:24 schrieb Fabian Grünbichler:
> >> On April 4, 2025 7:20 pm, Thomas Lamprecht wrote:
> >>> So, without looking at the implementation, fabrics have the IDs unique
> >>> per sub-type? Could maybe also share an ID space, less confusion
> >>> potential, but naturally also less flexibility – what do you think?
> >>
> >> they share a section config (and thus ID-space), so I guess we could
> 
> There's one section config file per fabric, so its ID is unique per
> protocol. We'd need to load *all* configuration files everytime we
> change one configuration file (at least when adding a fabric) so we can
> validate unique IDs across all fabric types.

mea culpa, must have mixed that up with something else (probably the
controllers :-/). would it make sense to merge them given the similarities?

> Since we have plans of moving over the existing IS-IS + BGP controllers,

those already have their own ACL paths, which makes this a bit messy then..
or does that mean the old controller config and endpoints will be removed
in favor of their counterparts in fabrics?

> as well as a new WireGuard fabric, we'd have to load and parse 5
> different configuration files for cross-validation then.
> 
> > Hmm, ok no real value for allowing a user use-access on such a fabric
> > (for now), and not sure if it is useful to allow certain admins to create
> > an openfabric fabric but not an ospf one (if the implementation even
> > uses such fine-grained checks)
> 
> I think that in practice, admins would create the fabrics and then only
> hand out permissions to edit that specific fabric, without handing out
> the permissions to create fabrics at all.
> 
> It might make sense for Wireguard (where the possible implications
> aren't nearly as bad as with e.g. BGP), but even then I think my
> previous point applies that you probably don't want to hand out blanket
> permissions for a whole subtype, in case you want to make heavy use of ACLs.
> 
> The current schema is more of a direct result of how the section config
> is structured, since IDs can be duplicated across different protocols,
> so you need the additional distinguisher in the ACL path.