Open Stack

On Wed, Aug 6, 2014 at 12:45 PM, Ryan Moats <rmoats at us.ibm.com> wrote:

> 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
>

Sorry, I don't follow what this port-create command does? Here ---
https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078
 --- shows that endpoint-groups map to networks so i'm confused why
network1 is coming into play here?


>
> 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
>

Mind mapping this to my example so we can see how to achieve the same thing
in group policy (with protocols and all)?  Looks like you would also need
to specify (--provided-contracts, --consumed-contracts) when you create the
endpoint-groups. Also, I don't see a cli command policy-apply so i'm not
sure really what that does.

>
>
> 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.
>

So are you saying that group policy doesn't allow us to do different
enforcement points on the same network as we do today?



>  Unlike security groups, GP allows more rich policy than just allow.
>


Right - I can see that GP does provide an allow/deny construct, though as
you pointed out we can extend the current security group concept in neutron
to provide allow/deny semantics to achieve the same thing no?


>
>
> 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
>
>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140806/eaf215fa/attachment.html>