<div dir="ltr">I am not able to say whether this works for Nova. Surely works for Neutron - from a functional perspective at least. <div><br></div><div>I still don't know however whether this choice is the best way to proceed, and perhaps you can help me understand better.</div><div><br></div><div>Role checks are always expressed through policy.json and can be enforced in middleware. Does this mean that there is also a centralized policy.json, or will we keep per-project policy files even for role checks?</div><div><br></div><div>Scope checks - ie: application-specific checks - can be enforced in any way the application developers wish. They can use policy.json, be hardcoded or, if they wish ask Pythia, the Oracle of Delphi. From an operator perspective, this means that every project can enforce policies in a different way. Is this going to be practical and maintainable? I can't speak for operators, but I would like to understand a bit better what this implies for them.</div><div><br></div><div>Salvatore</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 11 June 2015 at 17:47, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<p>The Neutron policy checks for things like </p>
<p><code> "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",<br>
<br>
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.<br>
</code></p>
<br>
<br>
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.<br>
<br>
Does this suggestion work for Nova? I think it will make the
overall policy much easier to maintain in the field.<br>
</div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>