Open Stack

Web tier can communicate with anything except for the DB.
App tier can only communicate with Web and DB.
DB can communicate with App.

These high-level constraints can then be implemented as security groups
like you showed, or network hardware ACLs like I had shown.
But if you start with the security groups API, you are forcing it to be
implemented there.


On Wed, Aug 6, 2014 at 6:06 PM, Aaron Rosen <aaronorosen at gmail.com> wrote:

>
>
>
> On Wed, Aug 6, 2014 at 4:46 PM, Kevin Benton <blak111 at gmail.com> wrote:
>
>> That's the point. By using security groups, you are forcing a certain
>> kind of enforcement that must be honored and might not be necessary if the
>> original intent was just to isolate between groups. In the example you
>> gave, it cannot be implemented on the router without violating the
>> constraints of the security group.
>>
>>
>> Hi Kevin,
>
> Mind proposing an alternative example then. The only way I can see this
> claim to be made is because Group Based policy is actually limiting what a
> tenants desired topology can be?
>
> Thanks,
>
> Aaron
>
>
>
>> On Wed, Aug 6, 2014 at 5:39 PM, Aaron Rosen <aaronorosen at gmail.com>
>> wrote:
>>
>>>
>>>
>>>
>>> On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton <blak111 at gmail.com> wrote:
>>>
>>>> >Given this information I don't see any reason why the backend system
>>>> couldn't do enforcement at the logical router and if it did so neither
>>>> parties would know.
>>>>
>>>> With security groups you are specifying that nothing can contact these
>>>> devices on those ports unless they come from the allowed IP addresses. If
>>>> you tried to enforce this at the router you would be violating that
>>>> specification because devices in the same subnet would be able to
>>>> communicate on those blocked ports.
>>>>
>>>
>>> Sure, though this is a problem of where you are doing your enforcement.
>>> If the backend system chooses to implement this optimization in this
>>> fashion (which was the example you gave previously [1]). Then, if the
>>> topology changes, i.e adding a port to the same network with conflicting
>>> security group rules, the backend system can no longer optimize in this
>>> same fashion at the router level and a more fine grain filtering will need
>>> to be done. How would this be any different with group based policy?
>>>
>>>
>>> [1] - With the latter, a mapping driver could determine that
>>> communication between these two hosts can be prevented by using an ACL on a
>>> router or a switch, which doesn't violate the user's intent and buys a
>>> performance improvement and works with ports that don't support security
>>> groups.
>>>
>>> states
>>>
>>>
>>>
>>>>
>>>>
>>>> On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen <aaronorosen at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On Wed, Aug 6, 2014 at 3:35 PM, Kevin Benton <blak111 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> By working at the port level you have already eliminated your ability
>>>>>> to implement the filtering at different components of the network. They now
>>>>>> need to be implemented in stateful rules at the port level and the device
>>>>>> has to support security groups.
>>>>>>
>>>>>
>>>>>
>>>>> Lets take this example where we setup a 2 tier app with web-servers
>>>>> and db-servers that are connected on two different networks attached to a
>>>>> router. We add a security group rules such that web-servers can talk to
>>>>> db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers from
>>>>> anywhere.
>>>>>
>>>>> neutron net-create web_net
>>>>> neutron subnet-create --name web_subnet web_net 10.0.0.0/24
>>>>>
>>>>> neutron net-create db_net
>>>>> neutron subnet-create --name db_subnet db_net 10.2.0.0/24
>>>>>
>>>>> neutron router-create myrouter
>>>>> neutron router-interface-add myrouter web_subnet
>>>>> neutron router-interface-add myrouter db_subnet
>>>>>
>>>>> neutron security-group-create  web-servers;
>>>>> neutron security-group-create db-servers;
>>>>>
>>>>> # add rule to allow web members to talk to the db-servers on TCP 3306
>>>>> for their db connection;
>>>>> neutron security-group-rule-create --protocol TCP --port-range-min
>>>>> 3306 --port-range-max 3306 --remote-group-id web-servers db-servers
>>>>>
>>>>> # add rule to allow TCP 80 into the web-server sg
>>>>> neutron security-group-rule-create --protocol TCP --port-range-min 80
>>>>> --port-range-max 80 web-servers db-servers
>>>>>
>>>>> # create some ports with desired security profiles.
>>>>> neutron port-create  --security-group web-servers web_net
>>>>> neutron port-create  --security-group web-servers web_net
>>>>>
>>>>> neutron port-create  --security-group db-servers db_net
>>>>> neutron port-create  --security-group db-servers db_net
>>>>>
>>>>>
>>>>> Now to your point:
>>>>>
>>>>> By working at the port level you have already eliminated your ability
>>>>>> to implement the filtering at different components of the network. They now
>>>>>> need to be implemented in stateful rules at the port level and the device
>>>>>> has to support security groups.
>>>>>>
>>>>>>
>>>>> Given this information I don't see any reason why the backend system
>>>>> couldn't do enforcement at the logical router and if it did so neither
>>>>> parties would know. The backend system should have the full graph of
>>>>> everything and be able to do enforcement optimizations where ever it likes.
>>>>>
>>>>> btw: I say the enforcement could be done on the logical router though
>>>>> the backend system could also do this on the physical fabic as well if it
>>>>> wanted to as it should also know that graph. No?
>>>>>
>>>>>
>>>>>>
>>>>>> On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen <aaronorosen at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton <blak111 at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> >I believe the referential security group rules solve this problem
>>>>>>>> (unless I'm not understanding):
>>>>>>>>
>>>>>>>> I think the disconnect is that you are comparing the way to current
>>>>>>>> mapping driver implements things for the reference implementation with the
>>>>>>>> existing APIs. Under this light, it's not going to look like there is a
>>>>>>>> point to this code being in Neutron since, as you said, the abstraction
>>>>>>>> could happen at a client. However, this changes once new mapping drivers
>>>>>>>> can be added that implement things differently.
>>>>>>>>
>>>>>>>> Let's take the security groups example. Using the security groups
>>>>>>>> API directly is imperative ("put a firewall rule on this port that blocks
>>>>>>>> this IP") compared to a higher level declarative abstraction ("make sure
>>>>>>>> these two endpoints cannot communicate"). With the former, the ports must
>>>>>>>> support security groups and there is nowhere except for the firewall rules
>>>>>>>> on that port to implement it without violating the user's expectation. With
>>>>>>>> the latter, a mapping driver could determine that communication between
>>>>>>>> these two hosts can be prevented by using an ACL on a router or a switch,
>>>>>>>> which doesn't violate the user's intent and buys a performance improvement
>>>>>>>> and works with ports that don't support security groups.
>>>>>>>>
>>>>>>>> Group based policy is trying to move the requests into the
>>>>>>>> declarative abstraction so optimizations like the one above can be made.
>>>>>>>>
>>>>>>>
>>>>>>> Hi Kevin,
>>>>>>>
>>>>>>> Interesting points. Though, let me ask this. Why do we need to move
>>>>>>> to a declarative API abstraction in neutron in order to perform this
>>>>>>> optimization on the backend? For example, In the current neutron model say
>>>>>>> we want to create a port with a security group attached to it called web
>>>>>>> that allows TCP:80 in and members who are in a security group called
>>>>>>> database. From this mapping I fail to see how it's really any different
>>>>>>> from the declarative model? The ports in neutron are logical abstractions
>>>>>>> and the backend system could be implemented in order to determine that the
>>>>>>> communication between these two hosts could be prevented by using an ACL on
>>>>>>> a router or switch as well.
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Aaron
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> OpenStack-dev mailing list
>>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OpenStack-dev mailing list
>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Kevin Benton
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenStack-dev mailing list
>>>>>> OpenStack-dev at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Kevin Benton
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Kevin Benton
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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