<div dir="ltr">Hi Everyone! <div><br></div><div>I've been reading through this thread and have had some conversations along the side and wanted to jump in to distill out what I think are the key points we are trying to address here. I'm going to outline about 4 items that seem to make sense to me regarding the evolution of policy. I also want to say that the "notification" that something has changed from the defaults in a way that may cause odd behavior to the side (the warning Sean was outlining); we can keep the desire to have those types of warnings for operators down the line (nothing that is being proposed here or what I'm going to outline will make it more or less difficult to add the functionality later on). This is not to say we wouldn't provide validation of an override, but a subjective "this is a problematic policy configuration" doesn't need to be directly part of this conversation today (it can happen once we know what the model of policy looks like going forward).</div><div><br></div><div>1. The first thing that I'm hearing from the conversation (this is based upon Sean's proposal) is that we already trust the individual projects to know the enforcement profile for their resources. It seems like the project should be authoritative on what that enforcement should look like. Handing off the enforcement definition to Keystone is the wrong direction. I really like the concept of defining within Nova the default policy that nova works with (we do this already today, and I don't want to require the nova team to come to Keystone to make changes to the policy down the line). The Projects are trusted to know what the enforcement points are and trusted to distribute a basic profile of enforcement. </div><div><br></div><div>To the end that the enforcement definition is handled by the individual projects, making it something that is more than a "blob of text" also makes a lot of sense. A code-like model that is easier to understand for the developers that are implementing enforcement would be useful. The key pieces are that this code-like-construct must be able to be serialized out into the "common" format. Second, this code-construct is just the basic level of "truth", the idea is that the dynamic policy will provide the overrides - and <b>everything</b> can be overridden.  The code-like construct will also aid in profiling/testing the base/defaults (and then the dynamic policy overrides) without having to standup the entire stack. We can enable base functionality testing / validation and then the more integrated testing with the full stack (in different environments). This will enable more accurate and better base policy development by the teams we already trust to build the enforcement for a given project (e.g. Nova).</div><div>--</div><div><br></div><div>2. We will need a way to handle the bi-directional notifications for policy changes. This would encompass when a project is restarted and has a new code-policy construct and how that gets to Keystone. We also need to ensure that changes to the overrides are pushed down to the projects. This is not an easy canned solution today, but I am sure we can solve it. Likely this is tied to Keystone Middleware or something similar (I believe code is already in the works to this end).</div><div>--</div><div><br></div><div>3. The HA-Proxy mode of deployment with projects that can handle no-downtime upgrades mean that we need to add in versioning into the policy structures. The policy files for a "Kilo" vintage of Nova may (likely) will be incompatible with "Liberty" nova. This means we cannot assume that policy can be centralized easily even for a specific grouping of api-services running as a single endpoint. This becomes an even more important mechanism as we move towards more and more services with microversioned APIs. It means it is totally reasonable to upgrade 1 or 2 nova APIs behind an HA Proxy since the new APIs will handle the old microversion of the API.</div><div><br></div><div>This leads to needing policy to likewise be versioned. This also means that only the service can be authoritative with the base-policy construct. This means whatever tool we use for handling the overrides on the Keystone side will need to be aware of policy versions as well. Having Keystone side being exclusively authoratative for the entire policy makes development, testing, and understanding of policy harder. This is another case of the project itself should be in control of the base policy definition. </div><div>--</div><div><br></div><div>4. As a note that came out of the conversation I had with Sean, we should look at no longer making the policy definition for an API keyed on the intern-method name of a project. While "instance_create" is relatively descriptive, there are many other API calls that you cannot really know what changing the policy will do without trying it. Sean and I were discussing moving towards supplying a representation of the URI path instead of "image_create". This is something that consumers and deployers of OpenStack will be more familiar with. It also eliminates some of the mapping needed to know what the URI of "image create" is when utilized in the Horizon context (asking Keystone "what can be done with authorization XXX").</div><div>--</div><div><br></div><div>All of the conversation in this thread and in IRC has been good. But I think we're at the point where we need to start setting a clear direction on the policy bits. All the recommendations have had merit and bring to the table interesting perspectives.</div><div><br></div><div>Lets start defining the next steps (this is not going to be easy) so we can start really working on the foundation we need to make all of this a reality.</div><div><br></div><div>--Morgan</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 4, 2015 at 12:00 PM, 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"><span class="">On 06/04/2015 01:16 PM, Sean Dague wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It gets overwritten by the central store.<br>
<br>
And you are wrong, that gives me what I want, because we can emit a<br>
WARNING in the logs if the patch is something crazy. The operators will<br>
see it, and be able to fix it later.<br>
<br>
I'm not trying to prevent people from changing their policy in crazy<br>
ways. I'm trying to build in some safety net where we can detect it's<br>
kind of a bad idea and emit that information a place that Operators can<br>
see and sort out later, instead of pulling their hair out.<br>
<br>
But you can only do that if you have encoded what's the default, plus<br>
annotations about ways that changing the default are unwise.<br>
</blockquote></span>
When would you expect this warning to be emitted, and to whom?  I think you have the right idea, but I suggest that the appropriate time to give that warning would be back when the policy is written, which would be under the scope of the Database-Driven policy management.  I would think that, if a user changes a policy, it would go to a staged state, not deployed immediately, and at that point, we'd want a check to run.  That check would be what told the author they did something unexpected.  Waiting until the policy hits the server is probably too late.<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<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>