Open Stack

On Thu, May 28, 2015 at 3:13 AM, Miguel Ángel Ajo <majopela at 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) <
> skandasw at 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 <vikschw at gmail.com>
> Date: Wednesday, May 27, 2015 at 5:54 PM
> To: OpenStack List <openstack-dev at 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 <mestery at mestery.com> wrote:
>
>  On Wed, May 27, 2015 at 5:36 PM, Eichberger, German <
> german.eichberger at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150528/3896b9a6/attachment.html>