Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenStack: Dev

inter-tenant and VM-to-bare-metal communication policies/restrictions.

 

 

OpenStack dev RSS feed   Index | Next | Previous | View Threaded


trapni at gmail

Jul 5, 2012, 8:47 AM

Post #1 of 4 (203 views)
Permalink
inter-tenant and VM-to-bare-metal communication policies/restrictions.

Hi all,

I am running multiple compute nodes and a single nova-network node, that is
to act
as a central gateway for the tenant's VMs.

However, since this nova-network node (of course) knows all routes, every
VM of
any tenant can talk to each other, including to the physical nodes, which
I highly disagree with and would like to restrict that. :-)

root [at] gw:~# ip route show
default via $UPLINK_IP dev eth1 metric 100
10.10.0.0/19 dev eth0 proto kernel scope link src 10.10.30.5
10.10.40.0/21 dev br100 proto kernel scope link src 10.10.40.1
10.10.48.0/24 dev br101 proto kernel scope link src 10.10.48.1
10.10.49.0/24 dev br102 proto kernel scope link src 10.10.49.1
$PUBLIC_NET/28 dev eth1 proto kernel scope link src $PUBLIC_IP
192.168.0.0/16 dev eth0 proto kernel scope link src 192.168.2.1

- 10.10.0.0/19 is the network for bare metal nodes, switches, PDUs, etc.
- 10.10.40.0/21(br100) is the "production" tenant
- 10.10.48.0/24 (br101) is the "staging" tenant
- 10.10.49.0/24 (br102) is the "playground" tenant.
- 192.168.0.0/16 is the legacy network (management and VM nodes)

No tenant's VM shall be able to talk to a VM of another tenant.
And ideally no tenant's VM should be able to talk to the management
network either.

Unfortunately, since we're migrating a live system, and we also have
production services on the bare-metal nodes, I had to add special routes
to allow the legacy installations to communicate to the new "production"
VMs for the transition phase. I hope I can remove that ASAP.

Now, checking iptables on the nova-network node:

root [at] gw:~# iptables -t filter -vn -L FORWARD
Chain FORWARD (policy ACCEPT 64715 packets, 13M bytes)
pkts bytes target prot opt in out source
destination
36M 29G nova-filter-top all -- * * 0.0.0.0/0
0.0.0.0/0
36M 29G nova-network-FORWARD all -- * * 0.0.0.0/0
0.0.0.0/0

root [at] gw:~# iptables -t filter -vn -L nova-filter-top
Chain nova-filter-top (2 references)
pkts bytes target prot opt in out source
destination
36M 29G nova-network-local all -- * * 0.0.0.0/0
0.0.0.0/0

root [at] gw:~# iptables -t filter -vn -L nova-network-local
Chain nova-network-local (1 references)
pkts bytes target prot opt in out source
destination

root [at] gw:~# iptables -t filter -vn -L nova-network-FORWARD
Chain nova-network-FORWARD (1 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- br102 * 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT all -- * br102 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT udp -- * * 0.0.0.0/0
10.10.49.2 udp dpt:1194
18M 11G ACCEPT all -- br100 * 0.0.0.0/0
0.0.0.0/0
18M 18G ACCEPT all -- * br100 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT udp -- * * 0.0.0.0/0
10.10.40.2 udp dpt:1194
106K 14M ACCEPT all -- br101 * 0.0.0.0/0
0.0.0.0/0
79895 23M ACCEPT all -- * br101 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT udp -- * * 0.0.0.0/0
10.10.48.2 udp dpt:1194

Now I see, that all traffic from tenant "staging" (br101) for example
allows any traffic from/to any destination (-j ACCEPT).
I'd propose to reduce this limitation to the public gateway interface (eth1
in my case) and that this value
shall be configurable in the nova.conf file.

Is there any other thing, I might have overseen, to disallow inter-tenant
communication and to disallow
tenant-VM-to-bare-metal communication?

Many thanks in advance,
Christian Parpart.


wolfgang.hennerbichler at risc-software

Jul 23, 2012, 2:18 AM

Post #2 of 4 (170 views)
Permalink
Re: inter-tenant and VM-to-bare-metal communication policies/restrictions. [In reply to]

On 07/23/2012 10:49 AM, Christian Parpart wrote:

> Am I (almost) the only one interested in disallowing inter-tenant
> communication, or am I overseeing something in the docs? :-(

I do have the same need, but I'm still fighting with other issues, so
I've not reached the piont to bitch about it :)

In my small world using vlans as separators and a (dedicated,
non-openstack-aware) firewall would be ideal.

> Christian.

Wolfgang

>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>


--
DI (FH) Wolfgang Hennerbichler
Software Development
Unit Advanced Computing Technologies
RISC Software GmbH
A company of the Johannes Kepler University Linz

IT-Center
Softwarepark 35
4232 Hagenberg
Austria

Phone: +43 7236 3343 245
Fax: +43 7236 3343 250
wolfgang.hennerbichler [at] risc-software
http://www.risc-software.at

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


lorin at nimbisservices

Aug 14, 2012, 7:16 PM

Post #3 of 4 (165 views)
Permalink
Re: inter-tenant and VM-to-bare-metal communication policies/restrictions. [In reply to]

On Jul 5, 2012, at 11:47 AM, Christian Parpart <trapni [at] gmail> wrote:

> Hi all,
>
> I am running multiple compute nodes and a single nova-network node, that is to act
> as a central gateway for the tenant's VMs.
>
> However, since this nova-network node (of course) knows all routes, every VM of
> any tenant can talk to each other, including to the physical nodes, which
> I highly disagree with and would like to restrict that. :-)
>

If you add this to nova.conf:

allow_same_net_traffic=false

It should prevent the VMs from communicating with each other. From

http://docs.openstack.org/essex/openstack-compute/admin/content/compute-options-reference.html#d6e3133


Take care,

Lorin
--
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.com


trapni at gmail

Aug 23, 2012, 7:15 AM

Post #4 of 4 (165 views)
Permalink
Re: inter-tenant and VM-to-bare-metal communication policies/restrictions. [In reply to]

On Wed, Aug 15, 2012 at 4:16 AM, Lorin Hochstein
<lorin [at] nimbisservices>wrote:

> On Jul 5, 2012, at 11:47 AM, Christian Parpart <trapni [at] gmail> wrote:
>
> Hi all,
>
> I am running multiple compute nodes and a single nova-network node, that
> is to act
> as a central gateway for the tenant's VMs.
>
> However, since this nova-network node (of course) knows all routes, every
> VM of
> any tenant can talk to each other, including to the physical nodes, which
> I highly disagree with and would like to restrict that. :-)
>
>
> If you add this to nova.conf:
>
> allow_same_net_traffic=false
>
> It should prevent the VMs from communicating with each other. From
>
>
> http://docs.openstack.org/essex/openstack-compute/admin/content/compute-options-reference.html#d6e3133
>

Hey Lorin,

according to this rather short documentation for that flag, it is
unfortunately very unclear what they meant with "from same network" - I
hope to misread that line :-)

That is, it sounds like it does prevent communication with ANY of the other
VMs, but I just want to disallow communication from one tenant to another.
Like, having a production tenant and a staging tenant, they should not be
able to talk to each other but a VM from the production tenant should be
able to
talk to another VM within the same tenant.

It might be helpful, if one may want to find some more clear words to this
flag within the flag reference :-)

I would also like to know on what physical hosts I need this flag to be
applied, too. I mean, is it just the nova-network node(s) or all compute
nodes, that this flag takes affect?

Many thanks in advance,
Christian Parpart.

OpenStack dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.