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. 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. 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. Thoughts? Tim ----- Original Message ----- | From: "Dolph Mathews" <dolph.math...@gmail.com> | To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> | Sent: Monday, November 11, 2013 3:10:01 PM | Subject: Re: [openstack-dev] Congress: an open policy framework | | | | | | | On Mon, Nov 11, 2013 at 4:28 AM, Flavio Percoco < fla...@redhat.com > | wrote: | | | | On 02/11/13 21:31 -0700, Tim Hinrichs wrote: | | | Hi OpenStackers, | | We've been working on an open policy framework for OpenStack that | we're calling Congress. We've been talking with OpenStack users and | several of our partners to understand the kinds of rules and | regulations they envision enforcing with a policy-based management | framework. Across the board they are interested in policies that | span networking, compute, storage, etc. | | The idea behind Congress is to have a single policy engine that | integrates any collection of external authentication and data stores | and allows cloud administrators to write policies over those data | stores in a rich, declarative language. The policy engine can either | enforce the policy proactively (i.e. preventing policy violations | before they occur) or reactively (identifying violations after they | occur and taking corrective action) or a combination (proactively | when possible and reactively when not). The policy engine can also | interact with the administrator, explaining the causes of | violations, computing potential remediation plans, and simulating | action executions to understand what violations those actions might | cause. | | While the project is still in the early stages, we have identified a | grammar for the policy language, implemented a policy engine, and | written a proof of concept integration for ActiveDirectory. We would | love to get participation and feedback. | | | Have you guys looked into oslo-incubator/policy.py ? | | What's wrong with the grammar used there? | | Have you guys considered starting your work from there? | | Although you're planning to create a policy service, it may make | sense | to be compliant with what OpenStack uses and maybe, you could | maintain | the whole policy library at some point. | | | | ++ I'm excited to see some new effort in this space (and sad that I | wasn't aware of this ahead of the summit), but surprised by the | apparent lack of integration with the existing oslo.policy engine, | centralized policy storage in keystone (/v3/policies), etc. There's | no reason why you couldn't replace all that, but a comparison with | the existing policy infrastructure to indicate the advantages | provided by congress (without making me read the source!) would be | help this gain some traction within community. | | | | FF | | -- | @flaper87 | Flavio Percoco | | | | ______________________________ _________________ | OpenStack-dev mailing list | OpenStack-dev@lists.openstack. org | http://lists.openstack.org/ cgi-bin/mailman/listinfo/ openstack-dev | | | | | -- | | | -Dolph | _______________________________________________ | OpenStack-dev mailing list | OpenStack-dev@lists.openstack.org | http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev | _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
