<div dir="ltr">From one operator's standpoint, some comments below.<br><div class="gmail_extra"><br></div><div class="gmail_extra">I can't imagine having to tell my customer base that we've just changed the 'default' security group from not allowing anything inbound, to allowing everything.  That would mean they would all have to strip the default group from all their instances (and modify their automated deployment tooling).</div><div class="gmail_extra"><br></div><div class="gmail_extra">In my mind, the default security group is there so that as people are developing their security policy they can at least start with a default that offers a small amount of protection.  Disabling that protection means I'd have to be dealing with a vast number of customers with instances that have been compromised because they didn't add to the security groups.</div><div class="gmail_extra"><br><div class="gmail_quote">On 3 March 2016 at 06:38, Sean M. Collins <span dir="ltr"><<a href="mailto:sean@coreitpro.com" target="_blank">sean@coreitpro.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 wrote:<br>
> * Instances without ingress are useless so a bunch of API calls are<br>
> required to make them useful.<br>
<br>
</span>This is not true in all cases. There are plenty of workloads that only<br>
require outbound connectivity. Workloads where data is fetched,<br>
computed, then transmitted elsewhere for storage.<br>
<span class=""><br></span></blockquote><div><br></div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> * It violates the end-to-end principle of the Internet to have a middle-box<br>
> meddling with traffic (the compute node in this case).<br>
<br>
</span>Again, this is someone's *opinion* - but it is not an opinion<br>
universally shared.<br></blockquote><div><br></div><div>+1 entire companies are built on the premise that people want firewalls</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br></span><span class="">> Second, would it be acceptable to make this operator configurable? This<br>
> would mean users could receive different default filtering as they moved<br>
> between clouds.<br></span></blockquote><div><br></div><div>If the default is to open it up, I'd want to change that regardless of other clouds.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
</span>It is my belief that an application that is going to be run in a cloud<br>
environment, it is not enough to just upload your disk image and expect<br>
that to be the only thing that is needed to run an app in the cloud. You<br>
will also need to bring your security policy into the cloud as well -<br>
Who can access? How can they access? Which parts of the app can talk to<br>
sensitive parts of the app like the database servers?<br>
<br></blockquote><div><br></div><div><br></div><div>This is entirely reasonable for anything remotely 'production', and I've not heard a single customer be even slightly surprised at this need.  I have, however, tripped up a number of times forgetting to allow inbound ssh and thinking I've misconfigured networking.</div><div><br></div><div>As people spin up dev instances for making apps, they would often think of security later down the path.  If they have some degree of protection from a default setting, that allows them to work with a little peace of mind.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think that the default security group should be left as is - and users<br>
should be trained that they should bring/create security groups with the<br>
appropriate rules for their need.<br></blockquote><div><br></div><div>+1</div><div> </div></div></div></div>