[openstack-dev] [neutron] - Changing the Neutron default security group rules
ihrachys at redhat.com
Thu Mar 3 11:28:44 UTC 2016
Salvatore Orlando <salv.orlando at gmail.com> wrote:
> On 3 March 2016 at 10:38, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
> Kevin Benton <kevin at benton.pub> wrote:
> 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
> 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,
> * 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.
More information about the OpenStack-dev