<html><body>
<p><tt><font size="2">Aaron Rosen <aaronorosen@gmail.com> wrote on 08/06/2014 02:12:05 PM:<br>
<br>
> From: Aaron Rosen <aaronorosen@gmail.com></font></tt><br>
<tt><font size="2">> To: "OpenStack Development Mailing List (not for usage questions)" <br>
> <openstack-dev@lists.openstack.org></font></tt><br>
<tt><font size="2">> Date: 08/06/2014 02:12 PM</font></tt><br>
<tt><font size="2">> Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy <br>
> and the way forward</font></tt><br>
<tt><font size="2">> <br>
> Hi Ryan, </font></tt><br>
<tt><font size="2">> <br>
> On Wed, Aug 6, 2014 at 11:55 AM, Ryan Moats <rmoats@us.ibm.com> wrote:</font></tt><br>
<tt><font size="2">> Jay Pipes <jaypipes@gmail.com> wrote on 08/06/2014 01:04:41 PM:<br>
> <br>
> [snip]</font></tt><br>
<tt><font size="2">> <br>
> <br>
> > AFAICT, there is nothing that can be done with the GBP API that cannot <br>
> > be done with the low-level regular Neutron API.<br>
</font></tt><br>
<tt><font size="2">> I'll take you up on that, Jay :)<br>
> <br>
> How exactly do I specify behavior between two collections of ports <br>
> residing in the same IP subnet (an example of this is a bump-in-the-<br>
> wire network appliance).<br>
</font></tt><br>
<tt><font size="2">> Would you mind explaining what behavior you want between the two <br>
> collection of ports? </font></tt><br>
<br>
<tt><font size="2">That's the point - I want a framework that will work regardless of the specifics of the behavior later on.</font></tt><br>
<br>
<tt><font size="2">> I've looked around regular Neutron and all I've come up with so far is:<br>
> (1) use security groups on the ports<br>
> (2) set allow_overlapping_ips to true, set up two networks with <br>
> identical CIDR block subnets and disjoint allocation pools and put a<br>
> vRouter between them.<br>
> <br>
> Now #1 only works for basic allow/deny access and adds the <br>
> complexity of needing to specify per-IP address security rules, <br>
> which means you need the ports to have IP addresses already and then<br>
> manually add them into the security groups, which doesn't seem <br>
> particularly very orchestration friendly.</font></tt><br>
<tt><font size="2">> <br>
> I believe the referential security group rules solve this problem <br>
> (unless I'm not understanding): </font></tt><br>
<tt><font size="2">> <br>
> neutron security-group-create group1</font></tt><br>
<tt><font size="2">> neutron security-group-create group2</font></tt><br>
<tt><font size="2">> <br>
> # allow members of group1 to ssh into group2 (but not the other way around):</font></tt><br>
<tt><font size="2">> neutron security-group-rule-create --direction ingress --port-range-<br>
> min 22 --port-range-max 22 --protocol TCP --remote-group-id group1 group2</font></tt><br>
<tt><font size="2">> <br>
> # allow members of group2 to be able to access TCP 80 from members <br>
> of group1 (but not the other way around): </font></tt><br>
<tt><font size="2">> neutron security-group-rule-create --direction ingress --port-range-<br>
> min 80 --port-range-max 80 --protocol TCP --remote-group-id group2 group1</font></tt><br>
<tt><font size="2">> <br>
> # Now when you create ports just place these in the desired security<br>
> groups and neutron will automatically handle this orchestration for <br>
> you (and you don't have to deal with ip_addresses and updates). </font></tt><br>
<tt><font size="2">> <br>
> neutron port-create --security-groups group1 network1</font></tt><br>
<tt><font size="2">> neutron port-create --security-groups group2 network1 </font></tt><br>
<br>
<tt><font size="2">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 :)</font></tt><br>
<br>
<tt><font size="2">> Now #2 handles both allow/deny access as well as provides a <br>
> potential attachment point for other behaviors, *but* you have to <br>
> know to set up the disjoint allocation pools, and your depending on <br>
> your drivers to handle the case of a router that isn't really a <br>
> router (i.e. it's got two interfaces in the same subnet, possibly <br>
> with the same address (unless you thought of that when you set things up)).<br>
<br>
> Are you talking about the firewall as a service stuff here? </font></tt><br>
<br>
<tt><font size="2">No, I'm being more general than any of the curret *aaS items, I'm thinking of the general service insertion case.</font></tt><br>
<br>
<tt><font size="2">> You can say that both of these are *possible*, but they both look <br>
> more complex to me than just having two groups of ports and <br>
> specifying a policy between them.</font></tt><br>
<tt><font size="2">> <br>
> Would you mind proposing how this is done in the Group policy api? <br>
> From what I can tell in the new proposed api you'd need to map both <br>
> of these groups to different endpoints i.e networks.</font></tt><br>
<br>
<tt><font size="2">Note: I'm not going to use the pure group policy API as I have been a fan of the</font></tt><br>
<tt><font size="2">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</font></tt><br>
<br>
<tt><font size="2">neutron grouppolicy-endpoint-group-create group1</font></tt><br>
<tt><font size="2">neutron grouppolicy-endpoint-group-create group2</font></tt><br>
<tt><font size="2">neutron port-create --endpoint-group group1 network1</font></tt><br>
<tt><font size="2">neutron port-create --endpoint-group group2 network1</font></tt><br>
<tt><font size="2">neutron grouppolicy-policy-action-create action</font></tt><br>
<tt><font size="2">neutron grouppolicy-policy-classifier-create classifier</font></tt><br>
<tt><font size="2">neutron grouppolicy-policy-rule-create --action action --classifier classifer rule</font></tt><br>
<tt><font size="2">neutron policy-apply rule group1 group2</font></tt><br>
<br>
<tt><font size="2">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.</font></tt><br>
<br>
<tt><font size="2">That of course begs the question of extending security groups (think this blueprint </font></tt><a href="https://review.openstack.org/#/c/93112/"><tt><font size="2">https://review.openstack.org/#/c/93112/</font></tt></a><tt><font size="2"> ) but that approach may have its own issues.</font></tt><br>
<br>
<tt><font size="2">Ryan</font></tt><br>
<br>
<br>
<br>
<tt><font size="2"> </font></tt></body></html>