On 13/11/13 10:40 -0800, Tim Hinrichs 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.
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.
In terms of ease integration with other projects, this sounds good.
However, it sounds like it'll add more complexity to policy.py than we
want.
That being said, I see the benefits of doing so, as long as policy.py
remains a library.
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 still have some doubts here, though. I know there's some work going
on around policy management - correct me, if I'm wrong - within
keystone. Have you looked into that?
Thoughts?
I know this may not be the right time to raise this, but I'll probably
forget about it later :D
Please, consider some kind of local cache within congress client
library as opposed to querying the API every single time. Policies
will be accessed a lot and it may become a performance penalty for
projects relying on congress.
Hope the above make sense.
Cheers,
FF
--
@flaper87
Flavio Percoco
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
