Open Stack

Hello Everyone,

This is 3rd proposal candidate for the Ussuri cycle community-wide goal. The other two are [1].

Colleen proposed this idea for the Ussuri cycle community goal. 

Projects implemented/plan to implement this:
*Keystone already implemented this with all necessary support in oslo.policy with nice documentation. 
* We discussed this in nova train PTG to implement it in nova [2]. Nova spec was merged in Train but
   could not implement. I have re-proposed the spec for the Ussuri cycle [3].  

This is nice idea as a goal from the user perspective. Colleen has less bandwidth to drive this goal alone. 
We are looking for a champion or co-champions (1-2 people will be much better) this goal along with Colleen.
 
Also, let us know what do you think of this as a community goal? Any query or Improvement Feedback?

You can refer the detailed on etherpad or I am copying the same here too to get feedback/queries in each
item. 
Existing policy defaults suffer from three major faults:
    #1: the admin-ness problem: use of policy rules like 'is_admin' or hard-coded is-admin checks results
             in the admin-anywhere-admin-everywhere problem and drastically inhibits true multitenancy since
            by default customers cannot have admin rights on their own projects or domains
    #2: insecure custom roles: many policy rules simply use "" as the rule, which means there
           is no rule: anyone can perform that action. This means creation of a custom role (say, "nova-autoscaler"
           requires editing every policy file across every service to block users with such a rule from performing
          actions unrelated to their role
    #3: related to #2, no support for read-only roles: keystone now has a "reader" role that comes out of the
            box when keystone is bootstrapped, but it currently has very little value because of the use of empty
           rules in service policies: users with the "reader" role can still perform write actions on services if the
          policy rule for such an action is empty.

The keystone project has migrated all of its default policies to 1) use oslo.policy's scope_types attribute,
which allows the policy engine to understand "system scope" and distinguish between an admin role 
assignment on a project versus an admin role assignment on the entire system, 2) ensure all rules use 
one of the default roles (admin, member, and reader) which both ensures support for a read-only role
and prevents custom roles from accidental over-permissiveness. Although the problems being solved
are slightly different, the keystone team found it was easiest to migrate everything at once. The rest of
the OpenStack services can use this migration as a template for securing their own policies.


[1] 
http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010287.html
http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010290.html
[2]  https://etherpad.openstack.org/p/ptg-train-xproj-nova-keystone
[3] https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:open+OR+status:merged)

-gmann