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 <ayo...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
