Kevin Benton <[email protected]> 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
rules.
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.
Ihar
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
