Open Stack

On 3 March 2016 at 10:38, Ihar Hrachyshka <ihrachys at redhat.com> wrote:

> 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.


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!
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.

Salvatore


>
> Ihar
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160303/1ceb864a/attachment.html>