[Openstack] Security group isolation on same physical host--perhaps needs to enhance openstack security on multihost model

romizhang1968 romizhang1968 at 163.com
Thu Jun 7 15:33:13 UTC 2012


Hi,
The same situation I also met,I think that would be security hole of openstack that should be resolved, hope someone could fix it.


If you use 1xNetwork+Nxcompute model, the VMs on compute node could not touch each other, but if you use multihost model, means each node run network+compute service, then even in different Tenant/VLAN/subnets,the VMs on a same host can get ip touch each other.
Through my testing,I thought the reason is, dnsmasq makes every VM use the bridge IP address as their default gateway and if you look the route table of compute node,there are all routed together.so VMs can touch each other,even if we do not allow icmp in the security group(but actually, the VM1 could touch VM2).
I try to use --gateway factor to set individual gateway for each Tenant/vlan/subnet through "nova-manage network create" process, but it is not useful for multihost mode,because dnsmasq would not create same ip address of different bridge on different nodes. the result is, dnsmasq ignore this factor and always use the lowest number x.x.x.1 to configure the bridge IP address. but when you use --gateway factor in 1xNetwork+NxCompute nodes, it can work,it set the bridge IP to your pointed.


If we want VM could touch the outside gateway,we can only use dnsmasq.conf to assign,but the question is, it can only set one Tenant network,not for multiple, but the reality is usually, we need VM touch outside different Network and can set its own gateway,do not use bridge IP as their gateway.
So, the question is right now,the security design of openstack is fine for 1xNetwork+NxCompute, but have a hole for multihost model.
To change the situation is easy, I suggest that:
1.dnsmasq use the lowest number of the tenant subnet IP address as the bridge IP address,just like current rules
2. if there is no "--gateway" assigned by "nova-manage network create" command, then to set the VM default gateway to the IP address of bridge;
2.if there is a "--gateway"  and then dnsmasq  set the default gateway of VM to that value but the bridge IP still is configured by dnsmasq using current rules, that means the lowest ip number of subnet.
If we can complete this,openstack could give us a many choicesof system designing and can route VM to the place we need,that can improve the network flexibility of openstack.


Wish someone could consider this view.


Regards,
Romi















At 2012-06-07 22:35:32,"Stephen Gran" <stephen.gran at guardian.co.uk> wrote:
>Hi,
>
>If they're in the same subnet, they won't go through a firewall to reach
>each other.  I'd imagine this is expected.
>
>Cheers,
>
>On Thu, 2012-06-07 at 10:00 -0400, Mitchell Broome wrote:
>> So I'm running into a problem where two different virtual machines on
>> the same physical host can get to each other bypassing security
>> groups.  As a test, I have removed all rules from the default security
>> group and created two other groups for testing (test1 and test2) that
>> only have inbound ssh access from a client network.  The hosts are on
>> 192.168.95.0/24 and the guest's fixed addresses are on
>> 192.168.97.0/24.  I'm not doing anything with floating ips, just
>> strictly fixed ips.  While testing, I'm using a single controller
>> running everything except nova-compute and a single compute host only
>> running nova-compute.
>> 
>> I'm using centos 6.2 with openstack from epel:
>> python-nova-2012.1-7.el6.noarch
>> openstack-nova-2012.1-7.el6.noarch
>> 
>> 
>> nova.conf (from the compute node):
>> http://paste.openstack.org/show/18381/
>> 
>> iptables -n -L:
>> http://paste.openstack.org/show/18382/
>> 
>> Is there some flag I'm missing in nova.conf to stop this?
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>
>-- 
>Stephen Gran
>Senior Systems Integrator - The Guardian
>
>Please consider the environment before printing this email.
>------------------------------------------------------------------
>Visit guardian.co.uk - newspaper of the year
>
>www.guardian.co.uk    www.observer.co.uk     www.guardiannews.com 
>
>On your mobile, visit m.guardian.co.uk or download the Guardian
>iPhone app www.guardian.co.uk/iphone
> 
>To save up to 30% when you subscribe to the Guardian and the Observer
>visit www.guardian.co.uk/subscriber 
>---------------------------------------------------------------------
>This e-mail and all attachments are confidential and may also
>be privileged. If you are not the named recipient, please notify
>the sender and delete the e-mail and all attachments immediately.
>Do not disclose the contents to another person. You may not use
>the information for any purpose, or store, or copy, it in any way.
> 
>Guardian News & Media Limited is not liable for any computer
>viruses or other material transmitted with or as part of this
>e-mail. You should employ virus checking software.
>
>Guardian News & Media Limited
>
>A member of Guardian Media Group plc
>Registered Office
>PO Box 68164
>Kings Place
>90 York Way
>London
>N1P 2AP
>
>Registered in England Number 908396
>
>
>_______________________________________________
>Mailing list: https://launchpad.net/~openstack
>Post to     : openstack at lists.launchpad.net
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120607/f415f76f/attachment.html>


More information about the Openstack mailing list