On 06/02/2015 06:27 PM, Morgan Fainberg wrote: > > > On Tue, Jun 2, 2015 at 12:09 PM, Adam Young <ayo...@redhat.com > <mailto:ayo...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev