On Wed, Aug 6, 2014 at 6:40 PM, Aaron Rosen <aaronoro...@gmail.com> wrote:
>
> On Wed, Aug 6, 2014 at 5:27 PM, Kevin Benton <blak...@gmail.com> wrote:
>
>> 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.
>>
>>
> I still have no idea what group based policy is buying us then. It seems
> to me that the key point we've identified going backing and forth here is
> the difference between the current model and the GBP model is that GBP
> constricts topology which allows us to write these types of enforcement
> rules. The reason we want this is because it yields performance
> optimizations (for some reason, which I don't think we've gotten into).
> Would you agree this is accurate?
>
>
Policy framework is a progression towards providing a richer configuration.
Network ACLs help with aggregation (network or other aggregations) and
attaching to broader bind points as opposed to just ports. Giving the
operator a choice of all options is necessary at this point with such
features being standard in public clouds (eg: VPC feature set in AWS)
Rudra
> Aaron
>
>
>
>>
>> On Wed, Aug 6, 2014 at 6:06 PM, Aaron Rosen <aaronoro...@gmail.com>
>> wrote:
>>
>>>
>>>
>>>
>>> On Wed, Aug 6, 2014 at 4:46 PM, Kevin Benton <blak...@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 <aaronoro...@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton <blak...@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 <aaronoro...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Wed, Aug 6, 2014 at 3:35 PM, Kevin Benton <blak...@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 <aaronoro...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton <blak...@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@lists.openstack.org
>>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> OpenStack-dev mailing list
>>>>>>>>> OpenStack-dev@lists.openstack.org
>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Kevin Benton
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> OpenStack-dev mailing list
>>>>>>>> OpenStack-dev@lists.openstack.org
>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OpenStack-dev mailing list
>>>>>>> OpenStack-dev@lists.openstack.org
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Kevin Benton
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenStack-dev mailing list
>>>>>> OpenStack-dev@lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev@lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Kevin Benton
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev@lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Kevin Benton
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
