[openstack-dev] [nova][neutron][devstack] New proposed 'default' network model
Mike Spreitzer
mspreitz at us.ibm.com
Tue Sep 15 20:32:22 UTC 2015
Clark Boylan <cboylan at sapwetik.org> wrote on 09/15/2015 04:06:26 PM:
> > I also strongly recommend to users to put vms on a private network and
> > use floating ip's/load balancers. For many reasons. Such as, if you
> > don't, the ip that gets assigned to the vm helps it become a pet. you
> > can't replace the vm and get the same IP. Floating IP's and load
> > balancers can help prevent pets. It also prevents security issues with
> > DNS and IP's. Also, for every floating ip/lb I have, I usually have 3x
or
> > more the number of instances that are on the private network. Sure its
> > easy to put everything on the public network, but it provides much
better
> > security if you only put what you must on the public network. Consider
> > the internet. would you want to expose every device in your house
> > directly on the internet? No. you put them in a private network and
poke
> > holes just for the stuff that does. we should be encouraging good
> > security practices. If we encourage bad ones, then it will bite us
later
> > when OpenStack gets a reputation for being associated with
compromises.
> There are a few issues with this. Neutron IPv6 does not support floating
> IPs. So now you have to use two completely different concepts for
> networking on a single dual stacked VM. IPv4 goes on a private network
> and you attach a floating IP. IPv6 is publicly routable. If security and
> DNS and not making pets were really the driving force behind floating
> IPs we would see IPv6 support them too. These aren't the reasons
> floating IPs exist, they exist because we are running out of IPv4
> addresses and NAT is everyones preferred solution to that problem. But
> that doesn't make it a good default for a cloud; use them if you are
> affected by an IP shortage.
>
> Nothing prevents you from load balancing against public IPs to address
> the DNS and firewall rule concerns (basically don't make pets). This
> works great and is how OpenStack's git mirrors work.
>
> It is also easy to firewall public IPs using Neutron via security groups
> (and possibly the firewall service? I have never used it and don't
> know). All this to say I think it is reasonable to use public shared
> networks by default particularly since IPv6 does not have any concept of
> a floating IP in Neutron so using them is just odd unless you really
> really need them and you aren't actually any less secure.
I'm really glad to see the IPv6 front opened.
But I have to say that the analysis of options for securing public
addresses omits one case that I think is important: using an external (to
Neutron) "appliance". In my environment this is more or less required.
This reinforces the bifurcation of addresses that was mentioned: some VMs
are private and do not need any service from the external appliance, while
others have addresses that need the external appliance on the
public/private path.
In fact, for this reason, I have taken to using two "external" networks
(from Neutron's point of view) --- one whose addresses are handled by the
external appliance and one whose addresses are not. In fact, both ranges
of address are on the same VLAN. This is FYI, some people have wondered
why these thins might be done.
> Not to get too off topic, but I would love it if all the devices in my
> home were publicly routable. I can use my firewall to punch holes for
> them, NAT is not required. Unfortunately I still have issues with IPv6
> at home. Maybe one day this will be a reality :)
Frankly, given the propensity for bugs to be discovered, I am glad that
nothing in my home is accessible from the outside (aside from the device
that does firewall, and I worry about that too). Not that this is really
germane to what we want to do for internet-accessible
applications/services.
Regards,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150915/9a398390/attachment.html>
More information about the OpenStack-dev
mailing list