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

Ihar Hrachyshka ihrachys at redhat.com
Thu Mar 3 09:38:00 UTC 2016

Kevin Benton <kevin at benton.pub> wrote:

> Hi,
> I know this has come up in the past, but some folks in the infra channel  
> brought up the topic of changing the default security groups to allow all  
> traffic.
> They had a few reasons for this that I will try to summarize here:
> * Ports 'just work' out of the box so there is no troubleshooting to  
> eventually find out that ingress is blocked by default.
> * Instances without ingress are useless so a bunch of API calls are  
> required to make them useful.
> * Some cloud providers allow all traffic by default (e.g. Digital Ocean,  
> RAX).
> * It violates the end-to-end principle of the Internet to have a  
> middle-box meddling with traffic (the compute node in this case).
> * Neutron cannot be trusted to do what it says it's doing with the  
> security groups API so users want to orchestrate firewalls directly on  
> their instances.
> So this ultimately brings up two big questions. First, can we agree on a  
> set of defaults that is different than the one we have now; and, if so,  
> how could we possibly manage upgrades where this will completely change  
> the default filtering for users using the API?

No. Such a change may expose existing users to breaches.

> Second, would it be acceptable to make this operator configurable? This  
> would mean users could receive different default filtering as they moved  
> between clouds.

While I am not happy that OpenStack cloud behaviour drift between setups; I  
accept that’s where we already are, having some clouds redefining default  

Considering reality we are already in, we could probably introduce  
configurable, API discoverable default rules.

If we go this route, I believe we should discourage feature usage by  
writing certification tests that validate those rules are *not* modified  
for any setup that claims DefCore compatibility.

Now, once we have it, it will be the user choice whether they want to  
complicate their orchestration code to deal with incompatibilities, or they  
just vote for DefCore compliant cloud.


More information about the OpenStack-dev mailing list