On 1 March 2016 at 14:52, Kevin Benton <ke...@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. >
What troubleshooting? If users were educated enough they would know that's the behavior to expect. > * Instances without ingress are useless so a bunch of API calls are > required to make them useful. > There are not. Besides, you're justing solving a problem to create another: a bunch of API calls to close ingress traffic! > * Some cloud providers allow all traffic by default (e.g. Digital Ocean, > RAX). > IMO, I think that's a loophole that should be closed. We should all strive to make OpenStack clouds behave alike. > * 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. > On what basis you're justifying these two last claims? > > > 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? > > Second, would it be acceptable to make this operator configurable? This > would mean users could receive different default filtering as they moved > between clouds. > A user can customize his/her own security groups rules ahead of booting instances, for all instances. Why wouldn't that suffice to address your needs? > > > Cheers, > Kevin Benton > > __________________________________________________________________________ > 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 > >
__________________________________________________________________________ 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
