Salvatore Orlando <[email protected]> wrote:
On 3 March 2016 at 10:38, Ihar Hrachyshka <[email protected]> wrote:
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.
Indeed. Even if the default are made discoverable via API changing them
will trigger upgrade mayhem.
API consumers will need to be aware that security group defaults might
differ across deployment first.
Now if we had a versioned API... but I won't go back there. Maybe just do
another extension, and all hail API evolution via extensions.
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.
So it seems you do not like the idea after all!
I don’t, but I sync my wishes with reality. :) What I don’t like even more
is huge cloud providers maintaining their own custom and [potentially]
mutually incompatible patches for the feature.
It would be interesting to see whether the DefCore committee reckons
there should a test verifying the enforcement of a "canonical" default
security group.
I honestly do not have an opinion in regard, but I would feel quite
disappointed if , for instance, my OpenStack implementation would not be
allowed to use the OpenStack trademark because I'm allowing users to ssh
into their floating IPs.
Some operators may just not care. If you run a private cloud in-house for
your developers, maybe using the trademark is not such a big deal for you.
Ihar
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
