Kevin, thank you for your help. Currently, we already have a similar patch for Pike release. We started this discuss that to pay attention to the degradation of flexibility and discuss to need to create a RFE.
2018-03-22 11:48 GMT+03:00 Kevin Benton <ke...@benton.pub>: > I understand. I think you will likely need to run a bit of custom code for > Pike if you want to override the default behavior of the port security > extension. You should be able to use something like the following > (untested) code as a service plugin. Install it somewhere on the server and > then put the import path to it in the service_plugins configuration. > > > > > from neutron_lib.api.definitions import port_security > from neutron_lib.callbacks import events > from neutron_lib.callbacks import registry > from neutron_lib.callbacks import resources > from neutron_lib.services import base > > > @registry.has_registry_receivers > class NetdefaultPortSecurity(base.ServicePluginBase): > > @registry.receives(resources.NETWORK, [events.BEFORE_CREATE]) > def force_default_portsec_false(self, rtype, event, trigger, context, > network, **kwargs): > network[port_security.PORTSECURITY] = False > > @classmethod > def get_plugin_type(cls): > return 'portsecdefaultoverride' > > def get_plugin_description(self): > return "workaround" > > > > To have this fixed in future versions I suggest filing an RFE to allow all > security to be disabled completely if the port security extension isn't > loaded. > > On Mon, Mar 19, 2018 at 9:34 AM, Vadim Ponomarev <ponoma...@selectel.ru> > wrote: > >> If I understood correctly, you talk about rules which are generated by >> security_group extension as default from the fixed_ips + >> allowed_address_pairs list. In our openstack installation we disabled the >> security_group and the allowed_address_pairs extensions to simplify the >> configuration the HA clusters. >> >> Currently we configure the neutron as follows: >> 1. prevent_arp_spoofing = False >> 2. disable security_group extension >> 3. disable allowed_address_pairs extension >> >> Actually, if port_security will be like a "central regulator" which >> controll all mechanisms, it's perfectly in our case. But, we will lose >> flexibility, because we can't changed default value for this option. And, >> even if we disable the port_security extension in the neutron, the prevent >> ARP-spoofing mechanism will work as default [1]. >> >> It's very important question, how do we may disable globally the prevent >> ARP spoofing in the Pike release? To create all networks without specifying >> an option port_security_enabled=False. >> >> Changes that were proposed by Tatiana, just let save current flexability. >> >> [1] https://github.com/openstack/neutron/blob/stable/pike/ne >> utron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L907 >> >> 2018-03-19 16:24 GMT+03:00 Kevin Benton <ke...@benton.pub>: >> >>> Disabling ARP spoofing protection alone will not let the standby >>> instance source traffic using the active instance's IP. IP filtering rules >>> independent of ARP enforcement rules ensure the source IP is in the >>> fixed_ips or allowed_address_pairs. >>> >>> Are you already using allowed address pairs to add the shared IP to both? >>> >>> On Mon, Mar 19, 2018, 22:13 Vadim Ponomarev <ponoma...@selectel.ru> >>> wrote: >>> >>>> Yes, there's really a need for mechanisms of high availability like >>>> corosync, vrrp etc. Another simple example: we have two servers with the >>>> active/standby HA configuration (for example keepalived + haproxy) and we >>>> have third-party monitoring system for these servers. The monitoring system >>>> gets some load metrics and when one of the servers is unavailable, the >>>> monitoring system scales architecture (adds new server to cluster) in this >>>> way saving the HA architecture. In your case, this monitoring system must >>>> do the following steps: create new instance, add new instance's MAC address >>>> to allowed_address_pairs and only after that reconfigure all other nodes. >>>> Otherwise cluster will not work. The solution to the problem is simple - >>>> disable the prevent ARP spoofing mechnism. >>>> >>>> Ok, we may used port_security options for this network with the HA >>>> cluster. For this case we must reconfigure our monitoring systems, create >>>> allowed_address_pairs for all current servers and (it's hardest) train our >>>> users how that done. >>>> >>>> Currently, we don't use the prevent ARP spoofing option >>>> (prevent_arp_spoofing = False) and honestly I don't understand why this >>>> option is enabled as default in private networks. Each such network belongs >>>> to one user, who controls all instances. Who would decide to perform a MITM >>>> attack in his own network? >>>> >>>> 2018-03-19 12:53 GMT+03:00 Kevin Benton <ke...@benton.pub>: >>>> >>>>> Do you need to spoof arbitrary addresses? If not (i.e. a set you know >>>>> ahead of time), you can put entries in the allowed_address_pairs field of >>>>> the port that will allow you to send traffic using other MAC/IPs. >>>>> >>>>> On Mar 19, 2018 8:42 PM, "Vadim Ponomarev" <ponoma...@selectel.ru> >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I support, that is a problem. It's unclear, how after removing the >>>>> option prevent_arp_spoofing, I can manage the prevent ARP spoofing >>>>> mechanism. Example: I use security groups but I don't want to use ARP >>>>> spoofing protection. How do I can disable the protection? >>>>> >>>>> 2018-03-14 10:26 GMT+03:00 Tatiana Kholkina <holk...@selectel.ru>: >>>>> >>>>>> Sure, there is an ability to enable ARP spoofing for the >>>>>> port/network, but it is impossible to make it enabled by default for all >>>>>> ports. >>>>>> It looks a bit complicated to me and I think it would be better to >>>>>> have an ability to set default port security via config file. >>>>>> >>>>>> Best regards, >>>>>> Tatiana >>>>>> >>>>>> 2018-03-13 15:10 GMT+03:00 Claudiu Belu <cb...@cloudbasesolutions.com >>>>>> >: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Indeed ARP spoofing is prevented by default, but AFAIK, if you want >>>>>>> it enabled for a port / network, you can simply disable the security >>>>>>> groups >>>>>>> on that neutron network / port. >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Claudiu Belu >>>>>>> >>>>>>> ------------------------------ >>>>>>> *From:* Татьяна Холкина [holk...@selectel.ru] >>>>>>> *Sent:* Tuesday, March 13, 2018 12:54 PM >>>>>>> *To:* openstack-dev@lists.openstack.org >>>>>>> *Subject:* [openstack-dev] [neutron] Prevent ARP spoofing >>>>>>> >>>>>>> Hi, >>>>>>> I'm using an ocata release of OpenStack where the option >>>>>>> prevent_arp_spoofing can be managed via conf. But later in pike it was >>>>>>> removed and it was decided to prevent spoofing by default. >>>>>>> There are cases where security features should be disabled. As I can >>>>>>> see now we can use a port_security option for these cases. But this >>>>>>> option >>>>>>> should be set for a particular port or network on create. The default >>>>>>> value >>>>>>> is set to True [1] and itt is impossible to change it. I'd like to >>>>>>> suggest to get default value for port_security [2] from config option. >>>>>>> It would be nice to know your opinion. >>>>>>> >>>>>>> [1] https://github.com/openstack/neutron-lib/blob/stable/que >>>>>>> ens/neutron_lib/api/definitions/port_security.py#L21 >>>>>>> [2] https://github.com/openstack/neutron/blob/stable/queens/ >>>>>>> neutron/objects/extensions/port_security.py#L24 >>>>>>> >>>>>>> Best regards, >>>>>>> Tatiana >>>>>>> >>>>>>> ____________________________________________________________ >>>>>>> ______________ >>>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>>> Unsubscribe: openstack-dev-requ...@lists.op >>>>>>> enstack.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.op >>>>>> enstack.org?subject:unsubscribe >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Vadim Ponomarev >>>>> Developer of network automation department at Selectel Ltd. >>>>> >>>>> ---- >>>>> This message may contain confidential information that can't be >>>>> distributed without the consent of the sender or the authorized person >>>>> Selectel >>>>> Ltd. >>>>> ____________________________________________________________ >>>>> ______________ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: openstack-dev-requ...@lists.op >>>>> enstack.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.op >>>>> enstack.org?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Vadim Ponomarev >>>> Developer of network automation department at Selectel Ltd. >>>> >>>> ---- >>>> This message may contain confidential information that can't be >>>> distributed without the consent of the sender or the authorized person >>>> Selectel >>>> Ltd. >>>> ____________________________________________________________ >>>> ______________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: openstack-dev-requ...@lists.op >>>> enstack.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.op >>> enstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> Best regards, >> Vadim Ponomarev >> Developer of network automation department at Selectel Ltd. >> >> ---- >> This message may contain confidential information that can't be >> distributed without the consent of the sender or the authorized person >> Selectel >> Ltd. >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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, Vadim Ponomarev Developer of network automation department at Selectel Ltd. ---- This message may contain confidential information that can't be distributed without the consent of the sender or the authorized person Selectel Ltd.
__________________________________________________________________________ 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
