Open Stack

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