Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options.
Hi, I had to patch the security groups to add the following rule, otherwise broadcast is blocked: -m pkttype --pkt-type multicast -j RETURN Ex: In /opt/stack/quantum/quantum/agent/linux/iptables_firewall.py def _allow_multicats_rule(self, iptables_rules): iptables_rules += ['-m pkttype --pkt-type multicast -j RETURN'] return iptables_rules def _convert_sgr_to_iptables_rules(self, security_group_rules): iptables_rules = [] self._drop_invalid_packets(iptables_rules) self._allow_established(iptables_rules) self._allow_multicats_rule(iptables_rules) From: Aaron Rosen [mailto:aro...@nicira.com] Sent: Wednesday, July 24, 2013 11:58 PM To: Samuel Bercovici Cc: OpenStack Development Mailing List; sorla...@nicira.com; Avishay Balderman; gary.kot...@gmail.com Subject: Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options. On Wed, Jul 24, 2013 at 12:42 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, This might be apparent but not to me. Can you point to how broadcast can be turned on a network/port? There is currently no way to prevent it so it's on by default. As for the https://github.com/openstack/neutron/blob/master/neutron/extensions/portsecurity.py, in NVP, does this totally disable port security on a port/network or it just disable the MAC/IP checks and still allows the user defined port security to take effect? Port security is currently obtained from the fixed_ips and mac_address field on the port. This removes the filtering done on fixed_ips and mac_address fields when disabled. This looks like an extension only implemented by NVP, do you know if there are similar implementations for other plugins? No, the other plugins do not currently have a way to disable spoofing dynamically (only globally disabled). Regards, -Sam. From: Aaron Rosen [mailto:aro...@nicira.commailto:aro...@nicira.com] Sent: Tuesday, July 23, 2013 10:52 PM To: Samuel Bercovici Cc: OpenStack Development Mailing List; sorla...@nicira.commailto:sorla...@nicira.com; Avishay Balderman; gary.kot...@gmail.commailto:gary.kot...@gmail.com Subject: Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options. I agree too. I've posted a work in progress of this here if you want to start looking at it: https://review.openstack.org/#/c/38230/ Thanks, Aaron On Tue, Jul 23, 2013 at 4:21 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, I agree that the AutZ should be separated and the service provider should be able to control this based on their model. For Service VMs who might be serving ~100-~1000 IPs and might use multiple MACs per port, it would be better to turn this off altogether that to have an IPTABLE rules with thousands of entries. This why I prefer to be able to turn-off IP spoofing and turn-off MAC spoofing altogether. Still from a logical model / declarative reasons an IP that can migrate between different ports should be declared as such and maybe also from MAC perspective. Regards, -Sam. From: Salvatore Orlando [mailto:sorla...@nicira.commailto:sorla...@nicira.com] Sent: Sunday, July 21, 2013 9:56 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options. On 19 July 2013 13:14, Aaron Rosen aro...@nicira.commailto:aro...@nicira.com wrote: On Fri, Jul 19, 2013 at 1:55 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, I have completely missed this discussion as it does not have quantum/Neutron in the subject (modify it now) I think that the security group is the right place to control this. I think that this might be only allowed to admins. I think this shouldn't be admin only since tenant's have control of their own networks they should be allowed to do this. I reiterate my point that the authZ model for a feature should always be completely separated by the business logic of the feature itself. In my opinion there are grounds both for scoping it as admin only and for allowing tenants to use it; it might be better if we just let the policy engine deal with this. Let me explain what we need which is more than just disable spoofing. 1. Be able to allow MACs which are not defined on the port level to transmit packets (for example VRRP MACs)== turn off MAC spoofing For this it seems you would need to implement the port security extension which allows one to enable/disable port spoofing on a port. This would be one way of doing it. The other would probably be adding a list of allowed VRRP MACs, which should be possible with the blueprint pointed by Aaron. 2. Be able to allow IPs which are not defined on the port level to transmit packets (for example, IP used for HA service
Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options.
On Wed, Jul 24, 2013 at 12:42 AM, Samuel Bercovici samu...@radware.comwrote: Hi, ** ** This might be apparent but not to me. Can you point to how broadcast can be turned on a network/port? There is currently no way to prevent it so it's on by default. ** ** As for the https://github.com/openstack/neutron/blob/master/neutron/extensions/portsecurity.py, in NVP, does this totally disable port security on a port/network or it just disable the MAC/IP checks and still allows the “user defined” port security to take effect? Port security is currently obtained from the fixed_ips and mac_address field on the port. This removes the filtering done on fixed_ips and mac_address fields when disabled. This looks like an extension only implemented by NVP, do you know if there are similar implementations for other plugins? ** No, the other plugins do not currently have a way to disable spoofing dynamically (only globally disabled). ** Regards, -Sam. ** ** ** ** *From:* Aaron Rosen [mailto:aro...@nicira.com] *Sent:* Tuesday, July 23, 2013 10:52 PM *To:* Samuel Bercovici *Cc:* OpenStack Development Mailing List; sorla...@nicira.com; Avishay Balderman; gary.kot...@gmail.com *Subject:* Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options. ** ** I agree too. I've posted a work in progress of this here if you want to start looking at it: https://review.openstack.org/#/c/38230/ ** ** Thanks, Aaron ** ** On Tue, Jul 23, 2013 at 4:21 AM, Samuel Bercovici samu...@radware.com wrote: Hi, I agree that the AutZ should be separated and the service provider should be able to control this based on their model. For Service VMs who might be serving ~100-~1000 IPs and might use multiple MACs per port, it would be better to turn this off altogether that to have an IPTABLE rules with thousands of entries. This why I prefer to be able to turn-off IP spoofing and turn-off MAC spoofing altogether. Still from a logical model / declarative reasons an IP that can migrate between different ports should be declared as such and maybe also from MAC perspective. Regards, -Sam. *From:* Salvatore Orlando [mailto:sorla...@nicira.com] *Sent:* Sunday, July 21, 2013 9:56 PM *To:* OpenStack Development Mailing List *Subject:* Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options. On 19 July 2013 13:14, Aaron Rosen aro...@nicira.com wrote: On Fri, Jul 19, 2013 at 1:55 AM, Samuel Bercovici samu...@radware.com wrote: Hi, I have completely missed this discussion as it does not have quantum/Neutron in the subject (modify it now) I think that the security group is the right place to control this. I think that this might be only allowed to admins. I think this shouldn't be admin only since tenant's have control of their own networks they should be allowed to do this. I reiterate my point that the authZ model for a feature should always be completely separated by the business logic of the feature itself. In my opinion there are grounds both for scoping it as admin only and for allowing tenants to use it; it might be better if we just let the policy engine deal with this. Let me explain what we need which is more than just disable spoofing.* *** 1. Be able to allow MACs which are not defined on the port level to transmit packets (for example VRRP MACs)== turn off MAC spoofing For this it seems you would need to implement the port security extension which allows one to enable/disable port spoofing on a port. This would be one way of doing it. The other would probably be adding a list of allowed VRRP MACs, which should be possible with the blueprint pointed by Aaron. 2. Be able to allow IPs which are not defined on the port level to transmit packets (for example, IP used for HA service that moves between an HA pair) == turn off IP spoofing It seems like this would fit your use case perfectly: https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairs 3. Be able to allow broadcast message on the port (for example for VRRP broadcast) == allow broadcast. Quantum does have an abstraction for disabling this so we already allow this by default. Regards, -Sam. *From:* Aaron Rosen [mailto:aro...@nicira.com] *Sent:* Friday, July 19, 2013 3:26 AM *To:* OpenStack Development Mailing List *Subject:* Re: [openstack-dev] Chalenges with highly available
Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options.
I agree too. I've posted a work in progress of this here if you want to start looking at it: https://review.openstack.org/#/c/38230/ Thanks, Aaron On Tue, Jul 23, 2013 at 4:21 AM, Samuel Bercovici samu...@radware.comwrote: Hi, ** ** I agree that the AutZ should be separated and the service provider should be able to control this based on their model. ** ** For Service VMs who might be serving ~100-~1000 IPs and might use multiple MACs per port, it would be better to turn this off altogether that to have an IPTABLE rules with thousands of entries. This why I prefer to be able to turn-off IP spoofing and turn-off MAC spoofing altogether. ** ** Still from a logical model / declarative reasons an IP that can migrate between different ports should be declared as such and maybe also from MAC perspective. ** ** Regards, -Sam. ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** *From:* Salvatore Orlando [mailto:sorla...@nicira.com] *Sent:* Sunday, July 21, 2013 9:56 PM *To:* OpenStack Development Mailing List *Subject:* Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options. ** ** ** ** ** ** On 19 July 2013 13:14, Aaron Rosen aro...@nicira.com wrote: ** ** ** ** On Fri, Jul 19, 2013 at 1:55 AM, Samuel Bercovici samu...@radware.com wrote: Hi, I have completely missed this discussion as it does not have quantum/Neutron in the subject (modify it now) I think that the security group is the right place to control this. I think that this might be only allowed to admins. I think this shouldn't be admin only since tenant's have control of their own networks they should be allowed to do this. ** ** I reiterate my point that the authZ model for a feature should always be completely separated by the business logic of the feature itself. In my opinion there are grounds both for scoping it as admin only and for allowing tenants to use it; it might be better if we just let the policy engine deal with this. Let me explain what we need which is more than just disable spoofing.* *** 1. Be able to allow MACs which are not defined on the port level to transmit packets (for example VRRP MACs)== turn off MAC spoofing ** ** For this it seems you would need to implement the port security extension which allows one to enable/disable port spoofing on a port. ** ** This would be one way of doing it. The other would probably be adding a list of allowed VRRP MACs, which should be possible with the blueprint pointed by Aaron. 2. Be able to allow IPs which are not defined on the port level to transmit packets (for example, IP used for HA service that moves between an HA pair) == turn off IP spoofing ** ** It seems like this would fit your use case perfectly: https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairs 3. Be able to allow broadcast message on the port (for example for VRRP broadcast) == allow broadcast. Quantum does have an abstraction for disabling this so we already allow this by default. Regards, -Sam. *From:* Aaron Rosen [mailto:aro...@nicira.com] *Sent:* Friday, July 19, 2013 3:26 AM *To:* OpenStack Development Mailing List *Subject:* Re: [openstack-dev] Chalenges with highly available service VMs Yup: I'm definitely happy to review and give hints. Blueprint: https://docs.google.com/document/d/18trYtq3wb0eJK2CapktN415FRIVasr7UkTpWn9mLq5M/edit https://review.openstack.org/#/c/19279/ patch that merged the feature; Aaron On Thu, Jul 18, 2013 at 5:15 PM, Ian Wells ijw.ubu...@cack.org.uk wrote: On 18 July 2013 19:48, Aaron Rosen aro...@nicira.com wrote: Is there something this is missing that could be added to cover your use case? I'd be curious to hear where this doesn't work for your case. One would need to implement the port_security extension if they want to completely allow all ips/macs to pass and they could state which ones are explicitly allowed with the allowed-address-pair extension (at least that is my current thought). Yes - have you got docs on the port security extension? All I've found so far are http://docs.openstack.org/developer/quantum/api/quantum.extensions.portsecurity.html and the fact that it's only the Nicira plugin that implements it. I could implement it for something else, but not without a few hints... -- Ian. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack
Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options.
Hi, I have completely missed this discussion as it does not have quantum/Neutron in the subject (modify it now) I think that the security group is the right place to control this. I think that this might be only allowed to admins. Let me explain what we need which is more than just disable spoofing. 1. Be able to allow MACs which are not defined on the port level to transmit packets (for example VRRP MACs)== turn off MAC spoofing 2. Be able to allow IPs which are not defined on the port level to transmit packets (for example, IP used for HA service that moves between an HA pair) == turn off IP spoofing 3. Be able to allow broadcast message on the port (for example for VRRP broadcast) == allow broadcast. Regards, -Sam. From: Aaron Rosen [mailto:aro...@nicira.com] Sent: Friday, July 19, 2013 3:26 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] Chalenges with highly available service VMs Yup: I'm definitely happy to review and give hints. Blueprint: https://docs.google.com/document/d/18trYtq3wb0eJK2CapktN415FRIVasr7UkTpWn9mLq5M/edit https://review.openstack.org/#/c/19279/ patch that merged the feature; Aaron On Thu, Jul 18, 2013 at 5:15 PM, Ian Wells ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk wrote: On 18 July 2013 19:48, Aaron Rosen aro...@nicira.commailto:aro...@nicira.com wrote: Is there something this is missing that could be added to cover your use case? I'd be curious to hear where this doesn't work for your case. One would need to implement the port_security extension if they want to completely allow all ips/macs to pass and they could state which ones are explicitly allowed with the allowed-address-pair extension (at least that is my current thought). Yes - have you got docs on the port security extension? All I've found so far are http://docs.openstack.org/developer/quantum/api/quantum.extensions.portsecurity.html and the fact that it's only the Nicira plugin that implements it. I could implement it for something else, but not without a few hints... -- Ian. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options.
Adding the original people conversing on this subject to this mail. Regards, -Sam. On Jul 19, 2013, at 11:57 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, I have completely missed this discussion as it does not have quantum/Neutron in the subject (modify it now) I think that the security group is the right place to control this. I think that this might be only allowed to admins. Let me explain what we need which is more than just disable spoofing. 1. Be able to allow MACs which are not defined on the port level to transmit packets (for example VRRP MACs)== turn off MAC spoofing 2. Be able to allow IPs which are not defined on the port level to transmit packets (for example, IP used for HA service that moves between an HA pair) == turn off IP spoofing 3. Be able to allow broadcast message on the port (for example for VRRP broadcast) == allow broadcast. Regards, -Sam. From: Aaron Rosen [mailto:aro...@nicira.com] Sent: Friday, July 19, 2013 3:26 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] Chalenges with highly available service VMs Yup: I'm definitely happy to review and give hints. Blueprint: https://docs.google.com/document/d/18trYtq3wb0eJK2CapktN415FRIVasr7UkTpWn9mLq5M/edit https://review.openstack.org/#/c/19279/ patch that merged the feature; Aaron On Thu, Jul 18, 2013 at 5:15 PM, Ian Wells ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk wrote: On 18 July 2013 19:48, Aaron Rosen aro...@nicira.commailto:aro...@nicira.com wrote: Is there something this is missing that could be added to cover your use case? I'd be curious to hear where this doesn't work for your case. One would need to implement the port_security extension if they want to completely allow all ips/macs to pass and they could state which ones are explicitly allowed with the allowed-address-pair extension (at least that is my current thought). Yes - have you got docs on the port security extension? All I've found so far are http://docs.openstack.org/developer/quantum/api/quantum.extensions.portsecurity.html and the fact that it's only the Nicira plugin that implements it. I could implement it for something else, but not without a few hints... -- Ian. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
