<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 6, 2014 at 12:45 PM, Ryan Moats <span dir="ltr"><<a href="mailto:rmoats@us.ibm.com" target="_blank">rmoats@us.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>
<p><tt><font>Aaron Rosen <<a href="mailto:aaronorosen@gmail.com" target="_blank">aaronorosen@gmail.com</a>> wrote on 08/06/2014 02:12:05 PM:<br>
<br>
> From: Aaron Rosen <<a href="mailto:aaronorosen@gmail.com" target="_blank">aaronorosen@gmail.com</a>></font></tt></p><div class=""><br>
<tt><font>> To: "OpenStack Development Mailing List (not for usage questions)" <br>
> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>></font></tt><br>
</div><tt><font>> Date: 08/06/2014 02:12 PM</font></tt><br>
<tt><font>> Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy <br>
> and the way forward</font></tt><br>
<tt><font>> <br>
> Hi Ryan, </font></tt><div class=""><br>
<tt><font>> <br>
> On Wed, Aug 6, 2014 at 11:55 AM, Ryan Moats <<a href="mailto:rmoats@us.ibm.com" target="_blank">rmoats@us.ibm.com</a>> wrote:</font></tt><br>
<tt><font>> Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>> wrote on 08/06/2014 01:04:41 PM:<br>
> <br>
> [snip]</font></tt><br>
<tt><font>> <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>> 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>> Would you mind explaining what behavior you want between the two <br>
> collection of ports? </font></tt><br>
<br>
</div><tt><font>That's the point - I want a framework that will work regardless of the specifics of the behavior later on.</font></tt><div><div class="h5"><br>
<br>
<tt><font>> 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>> <br>
> I believe the referential security group rules solve this problem <br>
> (unless I'm not understanding): </font></tt><br>
<tt><font>> <br>
> neutron security-group-create group1</font></tt><br>
<tt><font>> neutron security-group-create group2</font></tt><br>
<tt><font>> <br>
> # allow members of group1 to ssh into group2 (but not the other way around):</font></tt><br>
<tt><font>> 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>> <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>> 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>> <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>> <br>
> neutron port-create --security-groups group1 network1</font></tt><br>
<tt><font>> neutron port-create --security-groups group2 network1 </font></tt><br>
<br>
</div></div><tt><font>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><div class="">
<br>
<br>
<tt><font>> 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>
</div><tt><font>No, I'm being more general than any of the curret *aaS items, I'm thinking of the general service insertion case.</font></tt><div class=""><br>
<br>
<tt><font>> 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>> <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>
</div><tt><font>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>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>neutron grouppolicy-endpoint-group-create group1</font></tt><br>
<tt><font>neutron grouppolicy-endpoint-group-create group2</font></tt></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br>
<tt><font>neutron port-create --endpoint-group group1 network1</font></tt><br>
<tt><font>neutron port-create --endpoint-group group2 network1</font></tt></div></blockquote><div><br></div><div>Sorry, I don't follow what this port-create command does? Here --- <a href="https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078">https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078</a>  --- shows that endpoint-groups map to networks so i'm confused why network1 is coming into play here? </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br>
<tt><font>neutron grouppolicy-policy-action-create action</font></tt><br>
<tt><font>neutron grouppolicy-policy-classifier-create classifier</font></tt><br>
<tt><font>neutron grouppolicy-policy-rule-create --action action --classifier classifer rule</font></tt><br>
<tt><font>neutron policy-apply rule group1 group2</font></tt></div></blockquote><div><br></div><div>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.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br>
<br>
<tt><font>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.</font></tt></div>
</blockquote><div><br></div><div>So are you saying that group policy doesn't allow us to do different enforcement points on the same network as we do today?</div><div><span style="font-family:monospace"><br></span></div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><tt><font>  Unlike security groups, GP allows more rich policy than just allow.</font></tt></div>
</blockquote><div><br></div><div><br></div><div>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? </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br>
<br>
<tt><font>That of course begs the question of extending security groups (think this blueprint </font></tt><a href="https://review.openstack.org/#/c/93112/" target="_blank"><tt><font>https://review.openstack.org/#/c/93112/</font></tt></a><tt><font> ) but that approach may have its own issues.</font></tt><span class=""><font color="#888888"><br>

<br>
<tt><font>Ryan</font></tt><br>
<br>
<br>
<br>
<tt><font> </font></tt></font></span><p></p></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>