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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
