Open Stack

On 06/02/2015 06:27 PM, Morgan Fainberg wrote:
> 
> 
> On Tue, Jun 2, 2015 at 12:09 PM, Adam Young <ayoung at redhat.com
> <mailto:ayoung at redhat.com>> wrote:
> 
>     Since this a cross project concern, sending it out to the wider
>     mailing list:
> 
>     We have a sub-effort in Keystone to do better access control policy
>     (not the  Neutron or  Congress based policy efforts).
> 
>     I presented on this at the summit, and the effort is under full
>     swing.  We are going to set up a subteam meeting for this, but would
>     like to get some input from outside the Keystone developers working
>     on it.  In particular, we'd like input from the Nova team that was
>     thinking about hard-coding policy decisions in Python, and ask you,
>     instead, to work with us to come up with a solution that works for
>     all the service.
> 
> 
> I want to be sure we look at what Nova is presenting here. While
> building policy into python may not (on the surface) look like an
> approach that is wanted due to it restricting the flexibility that we've
> had with policy.json, I don't want to exclude the concept without
> examination. If there is a series of base level functionality that is
> expected to work with Nova in all cases - is that something that should
> be codified in the policy rules? This doesn't preclude having a mix
> between the two approaches (allowing custom roles, etc, but having a
> baseline for a project that is a known quantity that could be overridden).
> 
> Is there real value (from a UX and interoperability standpoint) to have
> everything 100% flexible in all the ways? If we are working to redesign
> how policy works, we should be very careful of excluding the (more)
> radical ideas without consideration. I'd argue that dynamic policy does
> fall on the opposite side of the spectrum from the Nova proposal. In
> truth I'm going to guess we end up somewhere in the middle.

I also don't think it's removing any flexibility at all. Moving the
default policy into code is about having sane defaults encoded somewhere
that we can analyze what people did with the policy, and WARN them when
they did something odd. That odd might be an interop thing, it might
also be 'you realize you disabled server creation, right, probably want
to go look at that'.

Our intent is this applies in layers.

You start with policy in code, that's a set of defaults, which can be
annotated with ("WARN if policy is restricted further than these
defaults") for specific rules.

Then you apply policy.json as a set of overrides. Compute and emit any
warnings.

Where this comes into dynamic policy I think is interesting, because
dynamic policy seems to require a few things.

Where is the start of day origin seed for policy?

There are a few options here. But if we think about a world where
components are releasing on different schedules, and being upgraded at
different times, it seems like the Nova installation has to be that
source of original truth.

So having a GET /policy API call that would provide the composite policy
that Nova knows about (code + json patch) would make a lot of sense. It
would make that discoverable to all kinds of folks on the network, not
just Keystone. Win.

This also seems like the only sane thing in a big tent world where
Keystone might have a *ton* of projects in it's catalog. When something
registered in the catalog, Keystone would reach back into that end point
and look for /policy and populate it's base source of truth for that
service from there.

Dynamic Policy overrides in Keystone would just be another set of
patches (conceptually). These stored in a database instead. Thats fine.

Where I get fuzzy on what I've read / discussed on Dynamic Policy right
now is the fact that every API call is going to need another round trip
to Keystone for a policy check (which would be db calls in keystone?)
Which, maybe is fine, but it seems like there are some challenges and
details around how this consolidated view of the world gets back to the
servers. It *almost* feels like that /policy API could be used to signal
catch flush as well on changes in Keystone (though we'd need to handle
the HA proxy case). I don't know, this seems a place where devil is in
the details, and lots of people probably need to weigh in on options.


But, the tl;dr is that Nova wanting to put defaults in code doesn't hide
anything away, and doesn't break the Dynamic policy model. It just adds
another layer that needs to be computed, and make it so that you'd get
the policy from Nova via that API instead of rooting around in the
filesystem (which is a far more useful way for most people to get it).

	-Sean

-- 
Sean Dague
http://dague.net