On Wed, Nov 13, 2013 at 10:40 AM, Tim Hinrichs <thinri...@vmware.com> wrote: > We're just getting started with Congress and understanding how it will > integrate with the OS ecosystem, but here's our current thinking about how > Congress relates to Oslo's policy engine and to Keystone. Comments and > suggestions are welcome. > > > Congress and Oslo > -------------------- > Three dimensions for comparison: policy language, data sources, and policy > engine. > > We've always planned to make Congress compatible with existing policy > languages like the one in oslo. The plan is to build a front-end for a > number of policy languages/formats, e.g. oslo-policy language, XACML, JSON, > YAML, SQL, etc. The idea being that the syntax/language you use is > irrelevant as long as it can be mapped into Congress's native policy > language. As of now, Congress is using Datalog, which is a variant of SQL > and is at least as expressive as all of the policy languages we've run across > in the cloud domain, including the oslo-policy language. > > In terms of the data sources you can reference in the policy, Congress is > designed to enable policies that reference arbitrary data sources in the > cloud. For example, we could write a Nova authorization policy that permits > a new VM to be created if that VM is connected to a network owned by a tenant > (info stored in Neutron) where the VM owner (info in the request) is in the > same group as the network owner (info stored in Keystone/LDAP). Oslo's > handles some of these data sources with its terminal rules, but it's not > involved in data integration to the same extent Congress is. > > In terms of policy engines, Congress is intended to enforce policies in 2 > different ways: proactively (stopping policy violations before they occur) > and reactively (acting to eliminate a violation after it occurs). Ideally we > wouldn't need reactive enforcement, but there will always be cases where > proactive enforcement is not possible (e.g. a DOS attack brings app latencies > out of compliance). The oslo-engine does proactive enforcement > only--stopping API calls before they violate the policy. >
Does this mean all policy decisions need to ask this new service? There are many policy checks that occur across even a given action (in some cases). Could this have a significant performance implication on larger scale cloud deployments? I like the idea of having reactive (DOS prevention) policy enforcement as well as external (arbitrary) data to help make policy decisions, I don't want to see Congress be limited in deployment because large scale clouds getting bottle-necked trying to communicate with it. > One concrete integration idea would be to treat Congress as a plugin for the > oslo-policy engine. This wouldn't enable say Nova to write policies that > take advantage of the expressiveness of Datalog, but it would give us > backwards compatibility. I'm sure that once Congress is available (and ready for prime-time) this type of mechanism will be mostly used for the transitional period. > > Congress and Keystone > ---------------------- > I see Keystone as providing two pieces of functionality: authentication and > group membership. Congress has nothing to do with authentication and never > will. Groups, on the other hand, are things we end up defining when writing > policies in Congress, so conceptually there's some overlap with Keystone. I > guess Congress could serve as a plugin/data source for Keystone and provide > it with the groups defined within the policy. This would allow a group to be > defined using data sources not available to Keystone, e.g. we could define a > group as all users who own a VM (info from Nova) connected to a network owned > by someone (info from Neutron) in the same group (info from LDAP). I don't > know how useful or efficient this would be, and it's certainly not something > we've designed Congress for. I have a concern about using the generic "group" terminology. As it stands "group" is a fairly overloaded term and fairly generic. If you have multiple group concepts when it comes to users it will cause confusion in discussion / understanding. Especially in the case of an IdP (Identity Provider) defining a "group" that has certain rights associated to it (e.g. "Can add projects in keystone") that is somehow overloaded by the policy engine when dealing with other services (name conflict) or even simpler requiring the understanding in the context of Congress groups or Groups that Keystone sees. While I am not opposed to a grouping mechanism within the policy engine, I want to make sure everyone has a clear understanding of the concepts being described (there was a recent issue with two concepts in keystone being called the same thing, and it has been a challenge to unwind that). There might be some value to seeing some work being done to provide more information to Keystone, but I think this will become more apparent as Congress develops. > Thoughts? > Tim > Cheers, Morgan Fainberg _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
