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

[Stefan Hanreich]

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.

Since we have plans of moving over the existing IS-IS + BGP controllers,
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.