Open Stack

Aaron Rosen <aaronorosen at gmail.com> wrote on 08/06/2014 02:12:05 PM:

> From: Aaron Rosen <aaronorosen at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Date: 08/06/2014 02:12 PM
> Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy
> and the way forward
>
> Hi Ryan,
>
> On Wed, Aug 6, 2014 at 11:55 AM, Ryan Moats <rmoats at us.ibm.com> wrote:
> Jay Pipes <jaypipes at gmail.com> wrote on 08/06/2014 01:04:41 PM:
>
> [snip]
>
>
> > AFAICT, there is nothing that can be done with the GBP API that cannot
> > be done with the low-level regular Neutron API.

> I'll take you up on that, Jay :)
>
> How exactly do I specify behavior between two collections of ports
> residing in the same IP subnet (an example of this is a bump-in-the-
> wire network appliance).

> Would you mind explaining what behavior you want between the two
> collection of ports?

That's the point - I want a framework that will work regardless of the
specifics of the behavior later on.

> I've looked around regular Neutron and all I've come up with so far is:
> (1) use security groups on the ports
> (2) set allow_overlapping_ips to true, set up two networks with
> identical CIDR block subnets and disjoint allocation pools and put a
> vRouter between them.
>
> Now #1 only works for basic allow/deny access and adds the
> complexity of needing to specify per-IP address security rules,
> which means you need the ports to have IP addresses already and then
> manually add them into the security groups, which doesn't seem
> particularly very orchestration friendly.
>
> I believe the referential security group rules solve this problem
> (unless I'm not understanding):
>
> neutron security-group-create group1
> neutron security-group-create group2
>
> # allow members of group1 to ssh into group2 (but not the other way
around):
> neutron security-group-rule-create --direction ingress --port-range-
> min 22 --port-range-max 22 --protocol TCP --remote-group-id group1 group2
>
> # allow members of group2 to be able to access TCP 80 from members
> of group1 (but not the other way around):
> neutron security-group-rule-create --direction ingress --port-range-
> min 80 --port-range-max 80 --protocol TCP --remote-group-id group2 group1
>
> # Now when you create ports just place these in the desired security
> groups and neutron will automatically handle this orchestration for
> you (and you don't have to deal with ip_addresses and updates).
>
> neutron port-create --security-groups group1 network1
> neutron port-create --security-groups group2 network1

While those rule instances aren't particularly interesting, I concede that
security groups can handle allow/deny. However, allow/deny is the least
interesting part of the problem :)

> Now #2 handles both allow/deny access as well as provides a
> potential attachment point for other behaviors, *but* you have to
> know to set up the disjoint allocation pools, and your depending on
> your drivers to handle the case of a router that isn't really a
> router (i.e. it's got two interfaces in the same subnet, possibly
> with the same address (unless you thought of that when you set things
up)).

> Are you talking about the firewall as a service stuff here?

No, I'm being more general than any of the curret *aaS items, I'm thinking
of the general service insertion case.

> You can say that both of these are *possible*, but they both look
> more complex to me than just having two groups of ports and
> specifying a policy between them.
>
> Would you mind proposing how this is done in the Group policy api?
> From what I can tell in the new proposed api you'd need to map both
> of these groups to different endpoints i.e networks.

Note: I'm not going to use the pure group policy API as I have been a fan
of the
2-group approach from day 1, I'm going to use the commands as stated in the
patch set, and I'm going to assume (dangerous I know) that I can specify
endpoint-group on port create

neutron grouppolicy-endpoint-group-create group1
neutron grouppolicy-endpoint-group-create group2
neutron port-create --endpoint-group group1 network1
neutron port-create --endpoint-group group2 network1
neutron grouppolicy-policy-action-create action
neutron grouppolicy-policy-classifier-create classifier
neutron grouppolicy-policy-rule-create --action action --classifier
classifer rule
neutron policy-apply rule group1 group2

One major difference between GP and current neutron (other than security
groups) is in your last statement about tying things to networks.  Like
security groups, groups in GP can have ports that span networks.  Unlike
security groups, GP allows more rich policy than just allow.

That of course begs the question of extending security groups (think this
blueprint https://review.openstack.org/#/c/93112/ ) but that approach may
have its own issues.

Ryan



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140806/c6655d37/attachment.html>