Re: [openstack-dev] [Openstack-security] Neutron security groups for L2 networks in Havana
Hi Aaron, I missed the latest mail of this thread in my mailbox, so pasting the content of your response below. *The issue is that the nova-api says that by default every instance needs tobe in a default security group that blocks all ingress traffic from outsideand allows all ingress from instances that belong to the same securitygroup. If an instance does not have an ip address we are unable to enforcethe instance-instance communication of members that are part of the samesecurity group (or at least the iptables implementation in place doesn't).There is an extension in neutron that implements port_security that allowsone to disable this so that one can do L2 networking as you want to. Thoughunfortunately, this does not work correctly at this time with nova ascurrently it's calling into neutron to create the security group and attachit to the instance anways. See: https://bugs.launchpad.net/nova/+bug/1175464 https://bugs.launchpad.net/nova/+bug/1175464 .I'm hoping to resolve this issue in the next few weeks.* *There is an extension in neutron that implements port_security that allows* *one to disable this so that one can do L2 networking as you want to. Though* *unfortunately, this does not work correctly at this time with nova as* *currently it's calling into neutron to create the security group and attach* *it to the instance anways. See: https://bugs.launchpad.net/nova/+bug/1175464 https://bugs.launchpad.net/nova/+bug/1175464 .* *I'm hoping to resolve this issue in the next few weeks.* Thanks a lot for the information. As per my understanding of the bug description and the code diff, the fix would prevent nova from adding 'default' security group if neutron is not specifying any security group, only for the case where there are plugins that implement port_security_api and have port_security_enabled=False I have two concerns here: 1. If we don't have any such plugins, then port_security is assumed to be enabled and again default security group would be added by nova, which mandates subnet and L2 networks does not work as expected. 2. If neutron provides security group(non default) via its own api or by means of security plugins, L2 networks still fail due to the same subnet issue. You may ask why security group is needed for L2 networks as the security rules are actually converted to iptables. The reason is that the vNIC may have ipaddress at later point of time and we can add security rules based on this ip then. I am just wondering why should the subnet be mandatory for the vNIC during the instance boot time. Regards, Kanthi On Fri, Nov 8, 2013 at 11:45 AM, Kanthi P pavuluri.kan...@gmail.com wrote: Hi Aaron, Thanks for the reply ! Yes security groups are mapped to L3/L4 headers, these security rules are being converted to iptables. If we remove the subnet check, we will be able to launch instances without ipaddress, they just have the mac address. Users can configure their own ipaddress after they are booted. If we use neutron security groups, it provides a default group (on port basis) which blocks all ingress and allows all egress traffic. Later users can configure security groups based on the ip address what they provided to the vnics. I mean to say, ports will have subnet but just that this subnet is not known to openstack during the instance boot time. On Fri, Nov 8, 2013 at 9:42 AM, Aaron Rosen aro...@nicira.com wrote: On Thu, Nov 7, 2013 at 12:23 PM, Kanthi P pavuluri.kan...@gmail.comwrote: Hi, I am trying to boot a VM which has a network without subnet in Havana, but it throws an exception saying that subnet is mandatory if quantum security groups are enabled. Here are the commands I used. neutron net-create testNet neutron net-show testNet +---+--+ | Field | Value| +---+--+ | admin_state_up| True | | id| 47208beb-2801-4729-bc7b-6532717232fc | | name | testNet | | provider:network_type | local| | provider:physical_network | | | provider:segmentation_id | | | router:external | False| | shared| False| | status| ACTIVE | | subnets | | | tenant_id | b5b591dcda2645cd9d15a4fe3eb1b50d | +---+--+ nova boot --flavor 2 --image 30c1984c-8a4f-4e3f-8c9a-7de0b321caa2 --nic net-id=47208beb-2801-4729-bc7b-6532717232fc testServer1 Here is the piece of code which
Re: [openstack-dev] [Openstack-security] Neutron security groups for L2 networks in Havana
Hi Kanthi,
The issue is that the nova-api says that by default every instance needs to
be in a default security group that blocks all ingress traffic from outside
and allows all ingress from instances that belong to the same security
group. If an instance does not have an ip address we are unable to enforce
the instance-instance communication of members that are part of the same
security group (or at least the iptables implementation in place doesn't).
There is an extension in neutron that implements port_security that allows
one to disable this so that one can do L2 networking as you want to. Though
unfortunately, this does not work correctly at this time with nova as
currently it's calling into neutron to create the security group and attach
it to the instance anways. See: https://bugs.launchpad.net/nova/+bug/1175464 .
I'm hoping to resolve this issue in the next few weeks.
Best,
Aaron
On Fri, Nov 8, 2013 at 1:45 AM, Kanthi P pavuluri.kan...@gmail.com wrote:
Hi Aaron,
Thanks for the reply !
Yes security groups are mapped to L3/L4 headers, these security rules are
being converted to iptables.
If we remove the subnet check, we will be able to launch instances without
ipaddress, they just have the mac address.
Users can configure their own ipaddress after they are booted.
If we use neutron security groups, it provides a default group (on port
basis) which blocks all ingress and allows all egress traffic.
Later users can configure security groups based on the ip address what
they provided to the vnics.
I mean to say, ports will have subnet but just that this subnet is not
known to openstack during the instance boot time.
On Fri, Nov 8, 2013 at 9:42 AM, Aaron Rosen aro...@nicira.com wrote:
On Thu, Nov 7, 2013 at 12:23 PM, Kanthi P pavuluri.kan...@gmail.comwrote:
Hi,
I am trying to boot a VM which has a network without subnet in Havana,
but it throws an exception saying that subnet is mandatory if quantum
security groups are enabled.
Here are the commands I used.
neutron net-create testNet
neutron net-show testNet
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| id| 47208beb-2801-4729-bc7b-6532717232fc |
| name | testNet |
| provider:network_type | local|
| provider:physical_network | |
| provider:segmentation_id | |
| router:external | False|
| shared| False|
| status| ACTIVE |
| subnets | |
| tenant_id | b5b591dcda2645cd9d15a4fe3eb1b50d |
+---+--+
nova boot --flavor 2 --image 30c1984c-8a4f-4e3f-8c9a-7de0b321caa2 --nic
net-id=47208beb-2801-4729-bc7b-6532717232fc testServer1
Here is the piece of code which generated this exception
nova/network/neutronv2/api.py
if (security_groups and not (
network['subnets']
and network.get('port_security_enabled', True))):
raise exception.SecurityGroupCannotBeApplied()
Can someone please explain why do we need this check?
Hi Kanthi,
We need this check because because in order to enforce security groups
the port needs to have an ip_address (i.e: network needs a subnet) since
Security groups only map to L3/4 headers. Today, nova automatically adds a
default security group to all instances when booted. Hopefully we can punt
this task off to neutron in this release by moving the port-creation up on
the stack to nova-api instead of nova-compute though this isn't the case
right now.
Aaron
To my understanding subnet is used for two purposes in terms of security
groups
1. To allow dhcp traffic if dhcp is enabled on the subnet, example given
below
-A quantum-openvswi-i7bf776d2-b -s 192.168.1.3/32 -p udp -m udp
--sport 67 --dport 68 -j RETURN
2. To avoid ip spoof
-A quantum-openvswi-o7bf776d2-b ! -s 192.168.1.2/32 -j DROP
Can we remove this so that we can have guests which has nic with just
MAC address, guest can configure its own ipaddress. Later if needed they
can enable their own security rules via quantum api.
___
Openstack-security mailing list
openstack-secur...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
