Open Stack

On 03/16/2015 02:59 PM, Tim Hinrichs wrote:
> Hi Adam,
>
> For the most part we've been looking at Congress policy as complementary to Oslo policy, so we haven’t yet tried to incorporate Oslo policy into Congress (though I did some experiments with that a while back).   But looking forward, it would definitely be convenient if there were some way to fetch Oslo policy from each of the components.

Good stuff.  Oslo Policy should be a generic rules engine.  We've been 
pretty good at keeping things that way, but Roles checking has Creeped 
in.  It should not mess up the other services to ignore that.

Probably a better, more scalable approach would be for an inheritance 
scheme, where by policy enforcement can inherit the core rules as well 
as rules specific to each project.  Fodder for the next summit.

>
> More inline...
>
>> On Mar 16, 2015, at 8:10 AM, Adam Young <ayoung at redhat.com> wrote:
>>
>> Oslo policy has been released as a stand alone library.  This is great, in that the rules engine is relatively non-applicaition specific, and I assume that all of the policy based project are planning to migrate over to using the policy library instead of the incubated version.
>>
>> Part of the push toward a more dynamic policy mechanism is figuring out how to fetch and cache the policy files from Keystone.  I suspect that the other services have the same issue.
> I thought each service would provide an API endpoint that would allow us to fetch their policy.json.  Why would we go through Keystone?
We agree.  Keystone here meant for the Keystone policy files.  Each 
service would supply its own form of content.
>> 1.  How long should a service hold on to the cached version of the policy file?
>> 2.  How can we avoid the stampeding herd if Keystone pushes out a notification change event?
>> 3.  How do we securely cache the file and still make it possible to debug.
>>
> I’m guessing performance won’t be a problem.  Policy.json is small, and there are likely few services listening to updates.
For Keystone, it is potentially every service in the catalog.  That 
might have an impact.

>
> Is the *content* of policy.json something sensitive that needs high security?  Months ago there was a thread about building a tool for analyzing policy.json to tell people which groups they would need to execute a given API call.  Wouldn’t that mean we’re probably not too concerned about people seeing the contents of policy.json?   I’m not saying we should broadcast policy.json to everyone who wants it, but it’s not clear to me we need to worry about protecting policy.json any more than administrator-level data returned by today’s API calls.
So, to get policy from Keysteon needs a Keystone token, which allows us 
to control "who gets what"  and I assume the other services want the 
potential to do the same thing.

>
>> The PKI tokens have a lot of these same issues, and have a one-off mechanism for handling it.  We should probably look in to commonizing this function.
>>
>> There general mechanism should be "fetch and cache" but I think it should not be tied to keystone token validation so much as capable of using it if necessary.  I'm guessing that access to policy rules are typically controlled by auth token validated services.  Is this correct?
>>
> If there were an API call for fetching policy, I would expect it to be protected just like any other API call.  And sure we’d provide whatever credentials are necessary to make that call.
Agreed.

>
> Tim
>
>> Maybe the right level of abstraction is a callback function for fetching the file to be cached, with the default being something that uses python-requests, and then an  auth plugin based alternative for those that require Keystone tokens.
>>
>> Before I go off and write a spec, I'd like to know what the prior art is here.  I'd also like to know if there oslo policy library is part of the plans for the other groups that are doing policy based work?
>>
>> __________________________________________________________________________
>> 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
> __________________________________________________________________________
> 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