Thank you all for investigating this. I came to the same conclusion while messing with the policy file: what Ghanshyam proposed, in fact, prevents the deletion also from any user created SG... As far as I understand there is no concept of "which SG group I'm dealing with" in the security group *rules* API, right? Anyway: I will file a bug report. Thank you, Paolo On 17/05/23 09:55, Slawek Kaplonski wrote:
[...]
'not' operator is supported in oslo policy. I think the below one should work which allows admin to delete the default SG and manager role
can delete only non-default SG.
NOTE: I have not tested this, may be you can check while trying other combinations.
"delete_security_group_rule": "role:project_manager and project_id:%(project_id)s and not 'default':%(name)s or 'default':%(name)s and role:admin"
-gmann
I checked it today and it can be done like:
"sg_is_default": "field:security_groups:name=default", "delete_security_group": "(role:member and project_id:%(project_id)s and not rule:sg_is_default) or role:admin"
for *Security Group*.
But it *won't work* like that *for security group rules* as You want to rely Your policy on the value of the attribute which belongs to parent resource (name of the Security group when doing API call for SG rule). We had similar problem for the "network:shared" field - see [1] and it was fixed with [2] but that fix is specific for this special field ("network:shared" only). Maybe we would need to add such special handling for the default security group as well. If You would like to have something like that, please open LP bug for it and we can investigate that deeper.
[1] https://bugs.launchpad.net/neutron/+bug/1808112 <https://bugs.launchpad.net/neutron/+bug/1808112>
[2] https://review.opendev.org/c/openstack/neutron/+/652636 <https://review.opendev.org/c/openstack/neutron/+/652636>
--
Slawek Kaplonski
Principal Software Engineer
Red Hat