<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 3 March 2016 at 10:38, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Kevin Benton <kevin@benton.pub> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
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.<br>
<br>
They had a few reasons for this that I will try to summarize here:<br>
* Ports 'just work' out of the box so there is no troubleshooting to eventually find out that ingress is blocked by default.<br>
* Instances without ingress are useless so a bunch of API calls are required to make them useful.<br>
* Some cloud providers allow all traffic by default (e.g. Digital Ocean, RAX).<br>
* It violates the end-to-end principle of the Internet to have a middle-box meddling with traffic (the compute node in this case).<br>
* 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.<br>
<br>
<br>
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?<br>
</blockquote>
<br></span>
No. Such a change may expose existing users to breaches.</blockquote><div><br></div><div>Indeed. Even if the default are made discoverable via API changing them will trigger upgrade mayhem.</div><div>API consumers will need to be aware that security group defaults might differ across deployment first.</div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Second, would it be acceptable to make this operator configurable? This would mean users could receive different default filtering as they moved between clouds.<br>
</blockquote>
<br></span>
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.<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Considering reality we are already in, we could probably introduce configurable, API discoverable default rules.<br>
<br>
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.<br>
<br>
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.</blockquote><div><br></div><div>So it seems you do not like the idea after all!</div><div>It would be interesting to see whether the DefCore committee reckons there should a test verifying the enforcement of a "canonical" default security group.</div><div>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.</div><div><br></div><div>Salvatore</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
Ihar</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>