Hi! ;) On Thursday, 28 de May de 2015 at 9:03, Gal Sagie wrote:
> Hello All, > > The session talk was mainly about merging the Security Group API and the > FWaaS API to the same one or to keep them separate, > Which i don't think we reached agreement (or did we? :) ) I can’t tell either ;) > > I personally think (And few people approached us in the summit to express > that they feel the same) that we need to allow the user the full set of > features > to be able to configure both on the "perimeter" firewall and on the VM port, > we can make the UI easier to apply a set of the features (similar to security > groups for example) > on the VM ports but i feel merging the API's would make things easier in the > long run (and then you can apply it either on the VM port or the router ports > and of course > choose to apply only a simpler subset of the features) I guess, the complexity here lies in deprecating the security group API while offering a migration path, probably proxying security group calls to FWaaS?, for full deprecation I guess you may need to coordinate with nova. FWaaS also lacks the ability to reference groups in rules, or is it capable of such thing? (ingress all from ‘sg-id’) Also you may want to make the FirewallDriver used for security groups part of FWaaS, and reuse/redesign the messaging mechanisms. I have mixed feelings about it, but I guess it could be a reasonable path so all the Firewall things are in one place, and not two. > > > There are many security use cases that are detected and handled better on the > Hypervisor / VM level which the current > security groups API doesn’t cover. > > For the staying compatible with Amazon argument, i understand and think its > important point, but there are already differences between different cloud > providers (For example if you take Azure its "Security Group" features > include actions) and i don’t think we need to hold off features and > innovation because others aren’t doing it. I agree, that we shouldn’t stop innovation even if others aren’t doing it, otherwise we’re putting a ceiling on our capabilities, and we’re always going to be behind proprietary/closed source public clouds... > > > We have already suggested and implemented (in review) easy way to extend new > rule classes for security groups [1], [2] > And have implemented one use case for this [3], [4] (brute force prevention) > (which we done a nice > research/analytic to create templates for common protocols login > rates/retries and how to detected brute force probabilities - > can extend in private if anyone is interested but everything can be seen in > the code) > > I also feel that auditing visibility is important for security groups and i > have a joint (with Roey Chen from VMware) API spec [5] > and reference implementation spec [6] to extend security groups auditing > capabilities > That came up into the “ovs sg ludicrous speed” talk, we may need auditing actions support in OvS at some point. Miguel Ángel Ajo, > None the less, would love to help and contribute code in any effort around > this area and would like to see this move forward, i believe we have > an opportunity to give added value to the users with this. > > Thanks > Gal. > > [1] https://review.openstack.org/#/c/169784/ > [2] https://review.openstack.org/#/c/154535/ > [3] https://review.openstack.org/#/c/151247/ > [4] https://review.openstack.org/#/c/184243/ > [5] https://review.openstack.org/#/c/180078/ > [6] https://review.openstack.org/#/c/180419/ > > On Thu, May 28, 2015 at 4:51 AM, Sridar Kandaswamy (skandasw) > <skand...@cisco.com (mailto:skand...@cisco.com)> wrote: > > Hi All: > > > > Thanks German for articulating this – we did have this discussion on last > > Fri as well on the need to have more user inputs. FWaaS has been in a bit > > of a Catch22 situation with the experimental state. Regarding feature > > velocity – it has definitely been frustrating and we also lost > > contributors along the journey due to their frustration with moving things > > forward making things worse. > > > > Kilo has been interesting in that there are more new contributors, repo > > split and more in terms of vendor support has gone in than ever before. We > > hope that this will improve traction for the customers they represent as > > well. Adding more user inputs and having a concerted conversation will > > definitely help. I echo Kyle and can certainly speak for all the current > > contributors in also helping out in any way possible to get this going. New > > Contributors are always welcome – Slawek & Vikram among the most recent > > new contributors know this well. > > > > Thanks > > > > Sridar > > > > From: Vikram Choudhary <viks...@gmail.com (mailto:viks...@gmail.com)> > > Date: Wednesday, May 27, 2015 at 5:54 PM > > To: OpenStack List <openstack-dev@lists.openstack.org > > (mailto:openstack-dev@lists.openstack.org)> > > Subject: Re: [openstack-dev] [neutron] [fwaas] - Collecting use cases for > > API improvements > > > > Hi German, > > > > Thanks for the initiative. I am currently working for few of the FWaaS BP's > > proposed for Liberty and definitely would like to be a part of this effort. > > > > > > BTW did you mean FWaaS IRC meeting to take up this discussion further? > > > > Thanks > > Vikram > > > > > > On Thu, May 28, 2015 at 4:20 AM, Kyle Mestery <mest...@mestery.com > > (mailto:mest...@mestery.com)> wrote: > > > On Wed, May 27, 2015 at 5:36 PM, Eichberger, German > > > <german.eichber...@hp.com (mailto:german.eichber...@hp.com)> wrote: > > > > All, > > > > > > > > > > > > During the FWaaS session in Vancouver [1] it became apparent that both > > > > the FWaaS API and the Security Groups API are lacking in functionality > > > > and the connection between the two is not well defined. > > > > > > > > > > > > For instance if a cloud user opens up all ports in the security groups > > > > they still can’t connect and might figure out days later that there is > > > > a second API (FWaaS) which prevents him from connecting to his service. > > > > This will probably make for a frustrating experience. > > > > > > > > > > > > Similarly, the operators I spoke to all said that the current FWaaS > > > > implementation isn’t going far enough and needs a lot of missing > > > > functionality added to fulfill their requirements on a Firewall > > > > implementation. > > > > > > > > > > > > With that backdrop I am proposing to take a step back and assemble a > > > > group of operators and users to collect use cases for the firewall > > > > service – both FWaaS and Security Groups based. I believe it is > > > > important at this juncture to really focus on the users and less on > > > > technical limitations. I also think this reset is necessary to make a > > > > service which meets the needs of operators and users better. > > > > > > > > > > > > Once we have collected the use cases we can evaluate our current API’s > > > > and functionality and start making the necessary improvements to turn > > > > FWaaS into a service which covers most of the use cases and > > > > requirements. > > > > > > > > > > > > Please join me in this effort. We have set up an etherpad [2] to start > > > > collecting the use cases and will discuss them in an upcoming meeting. > > > > > > > > > > Thanks for sending this out German. I took home the same impressions that > > > you did. Similar to what we did with the LBaaS project (to great success > > > last summer), I think we should look at FWaaS API V2 with the new > > > contributors coming on as equals and helping to define the new operator > > > focused API. My suggestion is we look at doing the work to lay the > > > foundation during Liberty for a successful launch of this API during the > > > Mxx cycle. I'm happy to step in here and guide the new group of > > > contributors similar to what we did for LBaaS. > > > > > > Thanks, > > > Kyle > > > > > > > > > > > Thanks, > > > > > > > > German > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > https://etherpad.openstack.org/p/YVR-neutron-sg-fwaas-future-direction > > > > > > > > [2] https://etherpad.openstack.org/p/fwaas_use_cases > > > > > > > > > > > > __________________________________________________________________________ > > > > OpenStack Development Mailing List (not for usage questions) > > > > Unsubscribe: > > > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > > > (http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe) > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > __________________________________________________________________________ > > > OpenStack Development Mailing List (not for usage questions) > > > Unsubscribe: > > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > > (http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe) > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > (http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe) > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > Best Regards , > > The G. > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > (mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
