[neutron] policy rules: filter on name field
Hello,
I'm trying to understand if this is feasible: I would like to avoid a regular user from tampering the "default" security group of a project. Specifically I would like to prevent him from deleting sg rules *from the default sg only*
I can wite a policy.yaml like this
# Delete a security group rule # DELETE /security-group-rules/{id} # Intended scope(s): project "delete_security_group_rule": "role:project_manager and project_id:%(project_id)s"
but this is sub-optimal since the regular member can still *add* rules...
Is it possible to create a rule like
"sg_is_default" : ...the sg group whose name is 'default'
so I can write
"delete_security_group_rule": "not rule:sg_is_default" ?
Thanks!
Paolo
Hi,
Dnia wtorek, 16 maja 2023 12:00:34 CEST Paolo Emilio Mazzon pisze:
Hello,
I'm trying to understand if this is feasible: I would like to avoid a regular user from tampering the "default" security group of a project. Specifically I would like to prevent him from deleting sg rules *from the default sg only*
I can wite a policy.yaml like this
# Delete a security group rule # DELETE /security-group-rules/{id} # Intended scope(s): project "delete_security_group_rule": "role:project_manager and project_id:%(project_id)s"
but this is sub-optimal since the regular member can still *add* rules...
Is it possible to create a rule like
"sg_is_default" : ...the sg group whose name is 'default'
so I can write
"delete_security_group_rule": "not rule:sg_is_default" ?
Thanks!
I'm not sure but I will try to check it later today or tomorrow morning and will let You know if that is possible or not.
Paolo
-- Paolo Emilio Mazzon System and Network Administrator
paoloemilio.mazzon[at]unipd.it
PNC - Padova Neuroscience Center https://www.pnc.unipd.it Via Orus 2/B - 35131 Padova, Italy +39 049 821 2624
---- On Tue, 16 May 2023 07:25:52 -0700 Slawek Kaplonski wrote ---
Hi,
Dnia wtorek, 16 maja 2023 12:00:34 CEST Paolo Emilio Mazzon pisze:
Hello,
I'm trying to understand if this is feasible: I would like to avoid a regular user from tampering the "default" security group of a project. Specifically I would like to prevent him from deleting sg rules *from the default sg only*
I can wite a policy.yaml like this
# Delete a security group rule # DELETE /security-group-rules/{id} # Intended scope(s): project "delete_security_group_rule": "role:project_manager and project_id:%(project_id)s"
but this is sub-optimal since the regular member can still *add* rules...
Is it possible to create a rule like
"sg_is_default" : ...the sg group whose name is 'default'
so I can write
"delete_security_group_rule": "not rule:sg_is_default" ?
Thanks!
I'm not sure but I will try to check it later today or tomorrow morning and will let You know if that is possible or not.
'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
Paolo
-- Paolo Emilio Mazzon System and Network Administrator
paoloemilio.mazzon[at]unipd.it
PNC - Padova Neuroscience Center https://www.pnc.unipd.it Via Orus 2/B - 35131 Padova, Italy +39 049 821 2624
-- Slawek Kaplonski Principal Software Engineer Red Hat
Hi,
Dnia wtorek, 16 maja 2023 23:52:39 CEST Ghanshyam Mann pisze:
---- On Tue, 16 May 2023 07:25:52 -0700 Slawek Kaplonski wrote ---
Hi,
Dnia wtorek, 16 maja 2023 12:00:34 CEST Paolo Emilio Mazzon pisze:
Hello,
I'm trying to understand if this is feasible: I would like to avoid a regular user from tampering the "default" security group of a project. Specifically I would like to prevent him from deleting sg rules *from the default sg only*
I can wite a policy.yaml like this
# Delete a security group rule # DELETE /security-group-rules/{id} # Intended scope(s): project "delete_security_group_rule": "role:project_manager and project_id:%(project_id)s"
but this is sub-optimal since the regular member can still *add* rules...
Is it possible to create a rule like
"sg_is_default" : ...the sg group whose name is 'default'
so I can write
"delete_security_group_rule": "not rule:sg_is_default" ?
Thanks!
I'm not sure but I will try to check it later today or tomorrow morning and will let You know if that is possible or not.
'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
Paolo-- Paolo Emilio Mazzon System and Network Administrator
paoloemilio.mazzon[at]unipd.it
PNC - Padova Neuroscience Center https://www.pnc.unipd.it Via Orus 2/B - 35131 Padova, Italy +39 049 821 2624
-- Slawek Kaplonski Principal Software Engineer Red Hat
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 [2] https://review.opendev.org/c/openstack/neutron/+/652636
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
---- On Wed, 17 May 2023 00:55:47 -0700 Slawek Kaplonski wrote ---
Hi,
Dnia wtorek, 16 maja 2023 23:52:39 CEST Ghanshyam Mann pisze:
---- On Tue, 16 May 2023 07:25:52 -0700 Slawek Kaplonski wrote --- > Hi, > > Dnia wtorek, 16 maja 2023 12:00:34 CEST Paolo Emilio Mazzon pisze: > > Hello, > > > > I'm trying to understand if this is feasible: I would like to avoid a regular user from > > tampering the "default" security group of a project. Specifically I would like to prevent > > him from deleting sg rules *from the default sg only* > > > > I can wite a policy.yaml like this > > > > # Delete a security group rule > > # DELETE /security-group-rules/{id} > > # Intended scope(s): project > > "delete_security_group_rule": "role:project_manager and project_id:%(project_id)s" > > > > but this is sub-optimal since the regular member can still *add* rules... > > > > Is it possible to create a rule like > > > > "sg_is_default" : ...the sg group whose name is 'default' > > > > so I can write > > > > "delete_security_group_rule": "not rule:sg_is_default" ? > > > > Thanks! > > I'm not sure but I will try to check it later today or tomorrow morning and will let You know if that is possible or not.
'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
> > > > > Paolo > > > > -- > > Paolo Emilio Mazzon > > System and Network Administrator > > > > paoloemilio.mazzon[at]unipd.it > > > > PNC - Padova Neuroscience Center > > https://www.pnc.unipd.it > > Via Orus 2/B - 35131 Padova, Italy > > +39 049 821 2624 > > > > > > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat
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.
++, default SG being a special case here, I agree on handling this case in code instead of making the configuration more complex. May be a separate policy for default SG can also make sense.
-gmann
[1] https://bugs.launchpad.net/neutron/+bug/1808112 [2] https://review.opendev.org/c/openstack/neutron/+/652636
-- Slawek Kaplonski Principal Software Engineer Red Hat
I've added https://bugs.launchpad.net/neutron/+bug/2019960 to the Neutron drivers meeting agenda (today at 14UTC). It will be discussed if we need to create new rules for the default SG and its rules (or any other proposal).
On Wed, May 17, 2023 at 5:38 PM Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Wed, 17 May 2023 00:55:47 -0700 Slawek Kaplonski wrote ---
Hi,
Dnia wtorek, 16 maja 2023 23:52:39 CEST Ghanshyam Mann pisze:
---- On Tue, 16 May 2023 07:25:52 -0700 Slawek Kaplonski wrote ---
Hi,
Dnia wtorek, 16 maja 2023 12:00:34 CEST Paolo Emilio Mazzon pisze:
Hello,
I'm trying to understand if this is feasible: I would like to
avoid a regular user from
tampering the "default" security group of a project.
Specifically I would like to prevent
him from deleting sg rules *from the default sg only*
I can wite a policy.yaml like this
# Delete a security group rule # DELETE /security-group-rules/{id} # Intended scope(s): project "delete_security_group_rule": "role:project_manager and
project_id:%(project_id)s"
but this is sub-optimal since the regular member can still *add*
rules...
Is it possible to create a rule like
"sg_is_default" : ...the sg group whose name is 'default'
so I can write
"delete_security_group_rule": "not rule:sg_is_default" ?
Thanks!
I'm not sure but I will try to check it later today or tomorrow
morning and will let You know if that is possible or not.
'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
Paolo-- Paolo Emilio Mazzon System and Network Administrator
paoloemilio.mazzon[at]unipd.it
PNC - Padova Neuroscience Center https://www.pnc.unipd.it Via Orus 2/B - 35131 Padova, Italy +39 049 821 2624
-- Slawek Kaplonski Principal Software Engineer Red Hat
I checked it today and it can be done like:
"sg_is_default": "field:security_groups:name=default", "delete_security_group": "(role:member andproject_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.
++, default SG being a special case here, I agree on handling this case in code instead of making the configuration more complex. May be a separate policy for default SG can also make sense.
-gmann
[1] https://bugs.launchpad.net/neutron/+bug/1808112 [2] https://review.opendev.org/c/openstack/neutron/+/652636
-- Slawek Kaplonski Principal Software Engineer Red Hat
Hi,
Dnia piątek, 19 maja 2023 11:57:12 CEST Rodolfo Alonso Hernandez pisze:
I've added https://bugs.launchpad.net/neutron/+bug/2019960 to the Neutron drivers meeting agenda (today at 14UTC). It will be discussed if we need to create new rules for the default SG and its rules (or any other proposal).
Thx Rodolfo.
On Wed, May 17, 2023 at 5:38 PM Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Wed, 17 May 2023 00:55:47 -0700 Slawek Kaplonski wrote ---
Hi,
Dnia wtorek, 16 maja 2023 23:52:39 CEST Ghanshyam Mann pisze:
---- On Tue, 16 May 2023 07:25:52 -0700 Slawek Kaplonski wrote ---
Hi,
Dnia wtorek, 16 maja 2023 12:00:34 CEST Paolo Emilio Mazzon pisze:
Hello,
I'm trying to understand if this is feasible: I would like to
avoid a regular user from
tampering the "default" security group of a project.
Specifically I would like to prevent
him from deleting sg rules *from the default sg only*
I can wite a policy.yaml like this
# Delete a security group rule # DELETE /security-group-rules/{id} # Intended scope(s): project "delete_security_group_rule": "role:project_manager and
project_id:%(project_id)s"
but this is sub-optimal since the regular member can still *add*
rules...
Is it possible to create a rule like
"sg_is_default" : ...the sg group whose name is 'default'
so I can write
"delete_security_group_rule": "not rule:sg_is_default" ?
Thanks!
I'm not sure but I will try to check it later today or tomorrow
morning and will let You know if that is possible or not.
'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
Paolo-- Paolo Emilio Mazzon System and Network Administrator
paoloemilio.mazzon[at]unipd.it
PNC - Padova Neuroscience Center https://www.pnc.unipd.it Via Orus 2/B - 35131 Padova, Italy +39 049 821 2624
-- Slawek Kaplonski Principal Software Engineer Red Hat
I checked it today and it can be done like:
"sg_is_default": "field:security_groups:name=default", "delete_security_group": "(role:member andproject_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.
++, default SG being a special case here, I agree on handling this case in code instead of making the configuration more complex. May be a separate policy for default SG can also make sense.
-gmann
[1] https://bugs.launchpad.net/neutron/+bug/1808112 [2] https://review.opendev.org/c/openstack/neutron/+/652636
-- Slawek Kaplonski Principal Software Engineer Red Hat
participants (4)
-
Ghanshyam Mann
-
Paolo Emilio Mazzon
-
Rodolfo Alonso Hernandez
-
Slawek Kaplonski