[nova] [ops] user_id based policy enforcement

Ghanshyam Mann gmann at ghanshyammann.com
Thu Jun 4 12:27:41 UTC 2020


---- On Wed, 03 Jun 2020 12:39:58 -0500 Massimo Sgaravatto <massimo.sgaravatto at gmail.com> wrote ----
 > Thanks again !
 > Out of curiosity, why the operation to access the console of an instance wasn't considered a "destructive action" ?This allows to send a ctrl-alt-del ...

Yeah, and there are other APIs also you can perform the destructive things. The idea of supporting the listed action for the user restriction was due to
keeping backward compatibility and give the operators some time to migrate and not to move the permission things from projects to user level.
That was around 4 years back and should have been removed now but we did not do. I think after new defaults it makes sense to remove those now.
I will check in PTG if all are ok to remove it.

-gmann

 > Cheers, Massimo
 > On Wed, Jun 3, 2020 at 7:18 PM Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
 >  ---- On Wed, 03 Jun 2020 11:17:41 -0500 Massimo Sgaravatto <massimo.sgaravatto at gmail.com> wrote ----
 >  > Thank you !
 >  > The "destructive actions" I guess are the ones listed here:
 >  > https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/user-id-based-policy-enforcement.html
 >  > 
 >  > In this page there is also the link to the ML thread you were talking about
 >  > So the user_id based policy enforcement for those destructive actions is supposed to work till Train ? Did I get it right ?
 > 
 > Yes, that is the exact list we kept the user_id restriction support for backword compatilbity. They will keep running till Ussuri for sure.
 > Please ntoe, we might cleanup those in Victoria cycle in favor of new defaults.
 > 
 > -gmann 
 > 
 >  > Thanks, Massimo
 >  > 
 >  > On Wed, Jun 3, 2020 at 3:53 PM Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
 >  >  ---- On Wed, 03 Jun 2020 01:18:41 -0500 Massimo Sgaravatto <massimo.sgaravatto at gmail.com> wrote ----
 >  >  > Hi
 >  >  > In my Rocky installation I am preventing users from deleting instances created by other users of the same project.This was implemented setting in the nova policy file:
 >  >  > 
 >  >  > "os_compute_api:servers:delete": "rule:admin_api or user_id:%(user_id)s"
 >  >  > 
 >  >  > This works, even if in the nova log file I see:
 >  >  > The user_id attribute isn't supported in the rule 'os_compute_api:servers:delete'. All the user_id based policy enforcement will be removed in the future.
 >  >  > 
 >  >  > Now I would also like preventing user to see the console log file of instances created by other users. I set in the nova policy file:
 >  >  > "os_compute_api:os-console-output" : "rule:admin_api or user_id:%(user_id)s"
 >  > 
 >  > Nova does not restrict the policy by user_id except keypairs API or a few of the destructive actions( which I think we supported for backwards compatiblity and
 >  > intent to remove it later that is why you can see the warning).  I remember we discussed this in 2016 but I could not find the ML thread for that but
 >  > the consensus that time was we do not intend to support user_id based restriction permission in the API.
 >  > 
 >  > On the same note,  ussuri onwards you can enforce some user-level restriction based on the role, but not by user_id. In the Ussuri cycle, we have implemented
 >  > the keystone new defaults roles in nova policy. You can assign read and write roles for users and achieve the user's isolation within same project. 
 >  > Please refer this doc to know more details on those new policies
 >  > - https://docs.openstack.org/nova/latest/configuration/policy-concepts.html
 >  > 
 >  > -gmann
 >  > 
 >  >  > 
 >  >  > but this doesn't work
 >  >  > Any hints ?
 >  >  > More in general: were the user_id based policy eventually removed in latest OpenStack releases ?Which are then the  possible alternatives to implement my use case ?
 >  >  > Thanks, Massimo
 >  > 
 > 



More information about the openstack-discuss mailing list