Open Stack

Hi Everyone!

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).

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.

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 *everything* 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).
--

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).
--

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.

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.
--

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").
--

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.

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.

--Morgan



On Thu, Jun 4, 2015 at 12:00 PM, Adam Young <ayoung at redhat.com> wrote:

> On 06/04/2015 01:16 PM, Sean Dague wrote:
>
>> It gets overwritten by the central store.
>>
>> And you are wrong, that gives me what I want, because we can emit a
>> WARNING in the logs if the patch is something crazy. The operators will
>> see it, and be able to fix it later.
>>
>> I'm not trying to prevent people from changing their policy in crazy
>> ways. I'm trying to build in some safety net where we can detect it's
>> kind of a bad idea and emit that information a place that Operators can
>> see and sort out later, instead of pulling their hair out.
>>
>> But you can only do that if you have encoded what's the default, plus
>> annotations about ways that changing the default are unwise.
>>
> 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.
>
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150604/e2f41940/attachment.html>