On Thu, May 28, 2015 at 3:13 AM, Miguel Ángel Ajo <majop...@redhat.com> wrote:
> 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. > > To be clear, the deprecation talk was the other way around. SG rules have been around much longer than FWaaS, and FWaaS hasn't had a release yet where it was not marked as experimental. Thus, the talk of looking holistically and seeing about rebooting it to get more traction and move it forward in a way that operators are comfortable with. > 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> 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> > Date: Wednesday, May 27, 2015 at 5:54 PM > To: OpenStack List <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> wrote: > > On Wed, May 27, 2015 at 5:36 PM, Eichberger, German < > 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://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 > > > > __________________________________________________________________________ > 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 > > > > > -- > Best Regards , > > The G. > > __________________________________________________________________________ > 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 > > > > __________________________________________________________________________ > 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 > >
__________________________________________________________________________ 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
