[nova] [ops] user_id based policy enforcement

Ghanshyam Mann gmann at ghanshyammann.com
Wed Jun 3 13:53:52 UTC 2020


 ---- 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