[openstack-dev] [nova][neutron][devstack] New proposed 'default' network model
Jeremy Stanley
fungi at yuggoth.org
Tue Sep 15 22:57:03 UTC 2015
On 2015-09-15 18:00:03 +0000 (+0000), Fox, Kevin M wrote:
> We run several clouds where there are multiple external networks.
> the "just run it in on THE public network" doesn't work. :/
Is this for a public servive provider? If so, do you expect your
users to have some premonition which tells them the particular
public network they should be choosing?
> 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.
I like pets just fine. Often I want pet servers not cattle servers.
Why should you (the service provider) make this choice for me?
> you can't replace the vm and get the same IP.
No? Well, you can `nova rebuild` in at least some environments, but
regardless it's not that hard to change a couple of DNS records when
replacing a server (virtual or physical).
> Floating IP's and load balancers can help prevent pets.
They can help prevent lots of things, some good, some bad. I'd
rather address translation were the exception, not the rule. NAT has
created a broken Internet.
> It also prevents security issues with DNS and IP's.
This is the first I've heard about DNS and IP addresses being
insecure. Please elaborate, and also explain your alternative
Internet which relies on neither of these.
> Also, for every floating ip/lb I have, I usually have 3x or more
> the number of instances that are on the private network.
Out of some misguided assumption that NAT is a security panacea from
the sound of it.
> 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.
I highly recommend a revolutionary new technology called "packet
filtering."
> Consider the internet. would you want to expose every device in
> your house directly on the internet? No.
On the contrary, I actually would (depending on what you mean by
"expose", but I assume from context you mean assign individual
global addresses directly to the network interfaces of each). With
IPv6 I do and would with v4 as well if my local provider routed me
more than a /32 assignment.
> you put them in a private network and poke holes just for the
> stuff that does.
No, I put them in a globally-routed network (the terms "private" and
"public" are misleading in the context of these sorts of
discussions) and poke holes just for the stuff that people need to
reach from outside that network.
> 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.
Here we agree, we just disagree on what those security practices
are. Address translation is no substitute for good packet filtering,
and allowing people to ignorantly assume so does them a great
disservice. We should be educating them on how to properly protect
their systems while at the same time showing them how much better
the Internet works without the distasteful workarounds brought about
by unnecessary layers of address-translating indirection.
And before this turns into a defense-in-depth debate, adding NAT to
your filtering doesn't really increase security it just increases
complexity.
> I do consider making things as simple as possible very important.
> but that is, make them as simple as possible, but no simpler.
> There's danger here of making things too simple.
Complexity is the enemy of security, so I find your reasoning
internally inconsistent. Proponents of NAT are suffering from some
manner of mass-induced Stockholm Syndrome. It's a hack to deal with
our oversubscription of the IPv4 address space and in some cases
solve address conflicts between multiple networks. Its unfortunate
ubiquity has confused lots of people into thinking it's there for
better reasons than it actually is.
--
Jeremy Stanley
More information about the OpenStack-dev
mailing list