[openstack-dev] [Congress] Policy types

Tim Hinrichs thinrichs at vmware.com
Wed Mar 19 23:44:04 UTC 2014


I went ahead and made an editing pass over our design doc to reflect the changes described below.  (I moved most of the old content into the final section focused on future work.)  Overall, I'd say it simplifies the story and implementation considerably.  We can always revert if anyone has serious objections, but it was a useful exercise to see if everything hangs together still (and it seems to).

I've also happened to talk with several different people about Congress since the last IRC, and the proposed changes are well-received.  

https://docs.google.com/a/vmware.com/document/d/1f2xokl9Tc47aV67KEua0PBRz4jsdSDLXth7dYe-jz6Q/edit#

Tim



----- Original Message -----
| From: "Tim Hinrichs" <thinrichs at vmware.com>
| To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
| Sent: Wednesday, March 12, 2014 10:05:23 AM
| Subject: [Congress] Policy types
| 
| Hi all,
| 
| We started a discussion on IRC yesterday that I'd like to continue. The main
| question is what kind of policy does a Congress user actually write? I can
| see three options. The first two focus on actions (API calls that make
| changes to the state of the cloud) and the last focuses on just the cloud
| state. (By "state of the cloud" I mean all the information Congress can see
| about all the cloud services it is managing, e.g. all the information we can
| get through API calls to Nova, Neutron, Cinder, Heat, ...).
| 
| 1) Access Control (e.g. Linux, XACML, AD): which *actions* can be performed
| by other cloud services (for each state of the cloud)
| 2) Condition Action: which *actions* Congress should execute (for each state
| of the cloud)
| 3) Classification (currently supported in Congress): which *states* violate
| real-world policy. [For those of you who have read docs/white-papers/etc.
| I'm using "Classification" in this note to mean the combination of the
| current "Classification" and "Action Description" policies.]
| 
| The important observation is that each of these policies could contain
| different information from each of the others.
| 
| - Access Control vs Condition Action. The Access Control policy tells *other
| cloud services* which actions they are *allowed* to execute. The Condition
| Action policy tells *Congress* which actions it *must* execute. These
| policies differ because they constrain different sets of cloud services.
| 
| - Access Control vs. Classification. The Access Control policy might permit
| some users to violate the Classification policy in some situations (e.g. to
| fix violation A, we might need to cause violation B before eliminating
| both). These policies differ because a violation in one policy might be be a
| violation in the other.
| 
| - Classification vs. Condition Action. The Classification policy might imply
| which actions *could* eliminate a given violation, but the Condition Action
| policy would dictate which of those actions *should* be executed (e.g. the
| Classification policy might tell us that disconnecting a network and
| deleting a VM would both eliminate a particular violation, but the Condition
| Action policy would tell us which to choose). And the Condition Action
| policy need not eliminate all the violations present in the Classification
| policy. Again these policies differ because a violation in one policy might
| not be a violation in the other.
| 
| I'm proposing that for the first release of Congress we support all 3 of
| these policies. When a user inserts/deletes a policy statement, she chooses
| which policy it belongs to. All would be written in basically the same
| syntax but would be used in 3 different scenarios:
| 
| - Prevention: If a component wants to consult Congress before taking action
| to see if that action is allowed, Congress checks the Access Control policy.
| 
| - Reaction: When Congress learns of a change in the cloud's state, it checks
| the Condition Action policy to see which actions should be executed (if
| any).
| 
| - Monitoring: If a user wants to simply check if the cloud's state is in
| compliance and monitor compliance over time, she writes and queries the
| Classification policy.
| 
| There are several benefits to this proposal.
| - It allows users to choose any of the policy types, if they only want one of
| them. From our discussions with potential users, most seem to want one of
| these 3 policy types (and are uninterested in the others).
| - It makes the introduction to Congress relatively simple. We describe 3
| different uses of policy (Prevention, Reaction, Monitoring) and then explain
| which policy to use in which case.
| - This allows us to focus on implementing a single policy-engine technology
| (a Datalog policy language and evaluation algorithms), which gives us the
| opportunity to make it solid.
| 
| There are drawbacks to this proposal as well.
| - We will have 3 separate policies that are conceptually very similar. As the
| policies grow larger, it will become increasingly difficult to keep the
| policies synchronized. This problem can be mitigated to some extent by
| having all 3 share a library of policy statements that they all apply in
| different ways (and such a library mechanism is already implemented).
| - As cloud services change their behavior, policies may need to be
| re-written. For example, right now Nova does not consult Congress before
| creating a VM; thus, to enforce policy surrounding VMs, the best we could do
| is write a Condition-Action policy that adjusts VM configuration when it
| learns about new VMs being created. If we later make Nova consult with
| Congress before creating a VM, we need to write an Access-control policy
| that puts the proper controls in place.
| 
| These drawbacks were the original motivation for supporting only the
| Classification policy and attempting to derive the Access Control and
| Condition Action policies from it. But given that we can't always derive the
| proper Access Control and Condition Action policies from the Classification
| policy, we will eventually need support for all 3. In addition, the
| technical complexity of supporting all 3 is much lower than supporting just
| the Classification policy and deriving the others.
| 
| I'll stop there for now.
| 
| Comments, thoughts, questions?
| Tim
| 



More information about the OpenStack-dev mailing list