SDN group/pool permissions

[neilz]

Hi all,

Just thought I'd let you know that the changes @spirit contributed have now been released into production. I updated our cluster this morning and have been able to test the sdn permissions. Users with access to a SDN vnet do not see the vmbr's unless you add a user/group permission path for /sdn/vnets/vmbrX (X being the number).

Thanks again @spirit

 

[spirit]

Hi all,

Just thought I'd let you know that the changes @spirit contributed have now been released into production. I updated our cluster this morning and have been able to test the sdn permissions. Users with access to a SDN vnet do not see the vmbr's unless you add a user/group permission path for /sdn/vnets/vmbrX (X being the number).

Thanks again @spirit

Thanks for the report !

 

[apollo13]

Hi all,

Just thought I'd let you know that the changes @spirit contributed have now been released into production. I updated our cluster this morning and have been able to test the sdn permissions. Users with access to a SDN vnet do not see the vmbr's unless you add a user/group permission path for /sdn/vnets/vmbrX (X being the number).

Thanks again @spirit

Mhm wasn't this reverted by https://git.proxmox.com/?p=pve-manager.git;a=commitdiff;h=a37ff602ff742403f01d6682bf9948183f87eadb again? If I read that code correctly it always shows vmbr* again now? Can you share your config -- are you on pve-manager 7.2-3?

 

[spirit]

Mhm wasn't this reverted by https://git.proxmox.com/?p=pve-manager.git;a=commitdiff;h=a37ff602ff742403f01d6682bf9948183f87eadb again? If I read that code correctly it always shows vmbr* again now? Can you share your config -- are you on pve-manager 7.2-3?

Well, proxmox dev wasn't too happy of the vnet to defined acl like /vnets/<vmbr> to diplay them again. (until a proper way to define permissions on vmbrX is added too).

Poke @fabian

 

[apollo13]

Well as I understood it the patch is not exactly backwards compatible so I understand that they didn't not have any option other than to restore the previous behavior. Given that permissions only allow access to stuff and can't hide stuff, this will be hard to add in a backwards compatible way. I wonder if a datacenter setting to hide all network interfaces but SDN ones would help [or similar, just trying to think outside the box].

 

[spirit]

Well as I understood it the patch is not exactly backwards compatible so I understand that they didn't not have any option other than to restore the previous behavior. Given that permissions only allow access to stuff and can't hide stuff, this will be hard to add in a backwards compatible way. I wonder if a datacenter setting to hide all network interfaces but SDN ones would help [or similar, just trying to think outside the box].

I think that Fabian want to wait for proxmox8, to disable access to vmbrX without permission by default (and add official acl). But, for now, maybe a global option indeed could help.

 

[fabian]

exactly - the problem is that giving access to one resource shouldn't hide other resources, and the 'sane' way to solve that is to wait for the next breaking change opportunity and then require positive ACLs for all of those resources (access control for configured bridges/networks is currently lacking anyhow, so this would be nice to have irrespective of the SDN features!).

we'd have to discuss whether an escape hatch (e.g., reverting back to the have SDN privs -> hide bridges behaviour, or a global toggle for opting-into the yet-to-be-written bridge-ACL feature ahead of the next major release, or ..) seems like a good idea.

also keep in mind that the patch only removed them from the list of bridges returned by the API, it didn't prevent using a regular bridge if interacting with the API directly (e.g., when configuring a guest), so it only provided a false sense of security anyway

 

[apollo13]

also keep in mind that the patch only removed them from the list of bridges returned by the API, it didn't prevent using a regular bridge if interacting with the API directly (e.g., when configuring a guest), so it only provided a false sense of security anyway

That is good to know, although in my case I am not trying to protect against malicious users but rather want to prevent myself and colleagues to do something we do not want to do. That said the expectation of ACLs would probably be that they actually have an effect, giving a false security impression is probably worse than not limiting the search box at all.