Open Stack

Sean had a really good point when he mentioned that the Developers know 
what need to be enforced, and I think this is why he suggested that the 
base policy implementation be in Python code, not the policy JSON DSL.

The main thrust of the dynamic policy has been to get the role-to-api 
assignment more flexible.  However, there is another side to each policy 
rule; figureing out where the project (nee' tenant) id is in the 
request;  is it part of the URL, part of the request body, or in the 
object returned from the database.  This part really should be handled 
by the developer working on the policy rule, and it should not be changed.

So...what if we say that we split policy into two checks;  a role check, 
and a scope check.  Both checks must pass in order for the user to get 
access to the API.  The Scope check is not going to be dynamic;  once 
set, they will pretty much stay set.   It might be done using the 
policy.json, or done in code, but it will be separate from the role check.


The Neutron policy checks for things like

|"shared": "field:networks:shared=True", "shared_firewalls": 
"field:firewalls:shared=True", "shared_firewall_policies": 
"field:firewall_policies:shared=True", "shared_subnetpools": 
"field:subnetpools:shared=True",

Would be handled by the dev teams later policy check; anything that 
requires actually fetching the object from the database is postponed to 
this stage.
|



The role check will come from the policy.json file.  This will allow the 
operator to fine tune how roles are handled.  Any thing else that can be 
explicitly checked based on the token will be fair game, but not API 
specific values;  no database fetch will be performed at this point.  
The assumption is that this policy check could be generic enough to be 
performed in middleware, and might even be enforced based on the URL 
instead of the pseudo random namespacing we do now.

Does this suggestion work for Nova?  I think it will make the overall 
policy much easier to maintain in the field.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150611/8f2cae26/attachment.html>