Open Stack

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 <kevin at 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 <ponomarev at 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 <kevin at 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 <ponomarev at 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 <kevin at 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" <ponomarev at 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 <holkina at 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 <cbelu at 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:* Татьяна Холкина [holkina at selectel.ru]
>>>>>>> *Sent:* Tuesday, March 13, 2018 12:54 PM
>>>>>>> *To:* openstack-dev at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180322/02078012/attachment.html>