<div dir="ltr"><div><div>I definitely buy the idea of layering policies on top of each
other. But I'd worry about the long-term feasibility of putting default
policies into code mainly because it ensures we'll never be able to provide any tools that help users (or other services like Horizon) know what the effective policy actually is. In contrast, if the code is just an implementation of the API, and there is some (or perhaps several) declarative description(s) of which of those APis are permitted to be executed by whom, we can build tools to analyze those policies. Two thoughts.<br><br></div>1) If the goal is to provide warnings to the user about questionable API policy choices, I'd suggest adding policy-analysis functionality to say oslo_policy. The policy-analysis code would take 2 inputs: (i) the policy and (ii) a list of policy properties, and would generate a warning if any of the properties are true for the given policy. Then each project could provide a file that describes which policy properties are questionable, and anyone wanting to see the warnings run the functionality on that project's policy and the project's policy property file.<br><br></div><div>It would definitely help me if we saw a handful of examples of the warnings we'd want to generate.<br><br></div><div>2) If the goal is to provide sensible defaults so the system functions if there's no policy.json (or a dynamic policy cached from Keystone), why not create a default_policy.json file and use that whenever policy.json doesn't exist (or more precisely to use policy.json to override default_policy.json in some reasonable way).<br><br></div><div>Tim<br></div><br><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 3, 2015 at 3:47 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 06/02/2015 06:27 PM, Morgan Fainberg wrote:<br>
><br>
><br>
> On Tue, Jun 2, 2015 at 12:09 PM, Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>>> wrote:<br>
><br>
> Since this a cross project concern, sending it out to the wider<br>
> mailing list:<br>
><br>
> We have a sub-effort in Keystone to do better access control policy<br>
> (not the Neutron or Congress based policy efforts).<br>
><br>
> I presented on this at the summit, and the effort is under full<br>
> swing. We are going to set up a subteam meeting for this, but would<br>
> like to get some input from outside the Keystone developers working<br>
> on it. In particular, we'd like input from the Nova team that was<br>
> thinking about hard-coding policy decisions in Python, and ask you,<br>
> instead, to work with us to come up with a solution that works for<br>
> all the service.<br>
><br>
><br>
> I want to be sure we look at what Nova is presenting here. While<br>
> building policy into python may not (on the surface) look like an<br>
> approach that is wanted due to it restricting the flexibility that we've<br>
> had with policy.json, I don't want to exclude the concept without<br>
> examination. If there is a series of base level functionality that is<br>
> expected to work with Nova in all cases - is that something that should<br>
> be codified in the policy rules? This doesn't preclude having a mix<br>
> between the two approaches (allowing custom roles, etc, but having a<br>
> baseline for a project that is a known quantity that could be overridden).<br>
><br>
> Is there real value (from a UX and interoperability standpoint) to have<br>
> everything 100% flexible in all the ways? If we are working to redesign<br>
> how policy works, we should be very careful of excluding the (more)<br>
> radical ideas without consideration. I'd argue that dynamic policy does<br>
> fall on the opposite side of the spectrum from the Nova proposal. In<br>
> truth I'm going to guess we end up somewhere in the middle.<br>
<br>
</div></div>I also don't think it's removing any flexibility at all. Moving the<br>
default policy into code is about having sane defaults encoded somewhere<br>
that we can analyze what people did with the policy, and WARN them when<br>
they did something odd. That odd might be an interop thing, it might<br>
also be 'you realize you disabled server creation, right, probably want<br>
to go look at that'.<br>
<br>
Our intent is this applies in layers.<br>
<br>
You start with policy in code, that's a set of defaults, which can be<br>
annotated with ("WARN if policy is restricted further than these<br>
defaults") for specific rules.<br>
<br>
Then you apply policy.json as a set of overrides. Compute and emit any<br>
warnings.<br>
<br>
Where this comes into dynamic policy I think is interesting, because<br>
dynamic policy seems to require a few things.<br>
<br>
Where is the start of day origin seed for policy?<br>
<br>
There are a few options here. But if we think about a world where<br>
components are releasing on different schedules, and being upgraded at<br>
different times, it seems like the Nova installation has to be that<br>
source of original truth.<br>
<br>
So having a GET /policy API call that would provide the composite policy<br>
that Nova knows about (code + json patch) would make a lot of sense. It<br>
would make that discoverable to all kinds of folks on the network, not<br>
just Keystone. Win.<br>
<br>
This also seems like the only sane thing in a big tent world where<br>
Keystone might have a *ton* of projects in it's catalog. When something<br>
registered in the catalog, Keystone would reach back into that end point<br>
and look for /policy and populate it's base source of truth for that<br>
service from there.<br>
<br>
Dynamic Policy overrides in Keystone would just be another set of<br>
patches (conceptually). These stored in a database instead. Thats fine.<br>
<br>
Where I get fuzzy on what I've read / discussed on Dynamic Policy right<br>
now is the fact that every API call is going to need another round trip<br>
to Keystone for a policy check (which would be db calls in keystone?)<br>
Which, maybe is fine, but it seems like there are some challenges and<br>
details around how this consolidated view of the world gets back to the<br>
servers. It *almost* feels like that /policy API could be used to signal<br>
catch flush as well on changes in Keystone (though we'd need to handle<br>
the HA proxy case). I don't know, this seems a place where devil is in<br>
the details, and lots of people probably need to weigh in on options.<br>
<br>
<br>
But, the tl;dr is that Nova wanting to put defaults in code doesn't hide<br>
anything away, and doesn't break the Dynamic policy model. It just adds<br>
another layer that needs to be computed, and make it so that you'd get<br>
the policy from Nova via that API instead of rooting around in the<br>
filesystem (which is a far more useful way for most people to get it).<br>
<span class="HOEnZb"><font color="#888888"><br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>