<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 06/11/2015 05:35 PM, Salvatore
Orlando wrote:<br>
</div>
<blockquote
cite="mid:CAGR=i3iXYmJz7P_rm4+dA3G1-uMUPDC-z9tH1akJiwK8hX4mWQ@mail.gmail.com"
type="cite">
<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>
</blockquote>
The focus of the centralized policy has always been the role
management. I don't propose changing course on that. We want the
role names to be consistant across all the projects.<br>
<br>
I see the starting lapproach being that users get one of two roles
by default; Administrator or Member. While these will still be
scoped to the project, only the role assignment itself would be
checked by the dynamic policy. The scope would be checked by static
policy.<br>
<br>
<blockquote
cite="mid:CAGR=i3iXYmJz7P_rm4+dA3G1-uMUPDC-z9tH1akJiwK8hX4mWQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</blockquote>
<br>
If the project already has logic doing the policy check using oslo,
and they want to keep using oslo, they can do so. Relaly,only
Keystone has any deep need to do so. The rules that I saw in Nova
were simple enough that they could be checked in oslo or with simple
python code. The limiting thing here is that the object in the
database needs to be checked against the scope anyway; it doesn't
matter if the scope on my token matches the scope on my roject as
specified in the URL, if the object fetched back does not belong to
that project. How this check is done differes from project to
project, it is just essential that the check be done.<br>
<br>
For a project that is not doing the check, and needs to start doing
so, it probably makes sense to use oslo.policy.<br>
<br>
<br>
Thanks for the questions<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAGR=i3iXYmJz7P_rm4+dA3G1-uMUPDC-z9tH1akJiwK8hX4mWQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>