[openstack-dev] [neutron] - Changing the Neutron default security group rules

Jeremy Stanley fungi at yuggoth.org
Wed Mar 2 21:47:13 UTC 2016

On 2016-03-02 21:25:25 +0000 (+0000), Sean M. Collins wrote:
> Jeremy Stanley wrote:
> > On 2016-03-03 07:49:03 +1300 (+1300), Xav Paice wrote:
> > [...]
> > > In my mind, the default security group is there so that as people
> > > are developing their security policy they can at least start with
> > > a default that offers a small amount of protection.
> > 
> > Well, not a small amount of protection. The instances boot
> > completely unreachable from the global Internet, so this is pretty
> > significant protection if you consider the most secure system is one
> > which isn't connected to anything.
> This is only if you are booting on a v4 network, which has NAT enabled.
> Many public providers, the network you attach to is publicly routed, and
> with the move to IPv6 - this will become more common. Remember, NAT is
> not a security device.

I agree that address translation is a blight on the Internet, useful
in some specific circumstances (such as virtual address load
balancing) but otherwise an ugly workaround for dealing with address
exhaustion and connecting conflicting address assignments. I'll be
thrilled when its use trails off to the point that newcomers cease
thinking that's what connectivity with the Internet is supposed to
be like.

What I was referring to in my last message was the default security
group policy, which blocks all ingress traffic. My point was that
dropping all inbound connections, while a pretty secure
configuration, is unlikely to be the desired configuration for
_most_ servers. The question is whether there's enough overlap in
different desired filtering policies to come up with a better
default than one everybody has to change because it's useful for
basically nobody, or whether we can come up with easier solutions
for picking between a canned set of default behaviors (per Monty's
suggestion) which users can expect to find in every OpenStack
environment and which provide consistent behaviors across all of
Jeremy Stanley

More information about the OpenStack-dev mailing list