On Mon, Mar 16, 2015 at 10: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. > > 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? > Why do you think this will present a problem? > 3. How do we securely cache the file and still make it possible to debug. > Why would security for policy blobs need to differ from today's implementation? (specifically referring to the side of the fence where policy blobs are consumed -- which is the only side of the fence today) > > 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? > Can you clarify this question/concern? > > 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