Looking at implementations in Keystone and Nova, I found the only use for is_admin but it is essential.
Whenever in code you need to run a piece of code with admin privileges, you can create a new context with is_admin=True keeping all other parameters as is, run code requiring admin access and then revert context back. My first though was: "Hey, why don't they just add 'admin' role then?". But what if in current deployment admin role is named like 'TheVerySpecialAdmin'? What if user has tweaked policy.json to better suite one's needs? So my current understanding is (and I suggest to follow this logic): - 'admin' role in context.roles can vary, it's up to cloud admin to set necessary value in policy.json; - 'is_admin' flag is used to elevate privileges from code and it's name is fixed; - policy check should assume that user is admin if either special role is present or is_admin flag is set. -- Kind regards, Yuriy.
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
