Open Stack

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 at 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 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
>  >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230519/49e6dca7/attachment.htm>