Open Stack

>From one operator's standpoint, some comments below.

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

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.

On 3 March 2016 at 06:38, Sean M. Collins <sean at coreitpro.com> wrote:

> Kevin Benton wrote:
> > * Instances without ingress are useless so a bunch of API calls are
> > required to make them useful.
>
> This is not true in all cases. There are plenty of workloads that only
> require outbound connectivity. Workloads where data is fetched,
> computed, then transmitted elsewhere for storage.
>
>
+1


> > * It violates the end-to-end principle of the Internet to have a
> middle-box
> > meddling with traffic (the compute node in this case).
>
> Again, this is someone's *opinion* - but it is not an opinion
> universally shared.
>

+1 entire companies are built on the premise that people want firewalls


>
> > Second, would it be acceptable to make this operator configurable? This
> > would mean users could receive different default filtering as they moved
> > between clouds.
>

If the default is to open it up, I'd want to change that regardless of
other clouds.


>
> It is my belief that an application that is going to be run in a cloud
> environment, it is not enough to just upload your disk image and expect
> that to be the only thing that is needed to run an app in the cloud. You
> will also need to bring your security policy into the cloud as well -
> Who can access? How can they access? Which parts of the app can talk to
> sensitive parts of the app like the database servers?
>
>

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.

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.



> I think that the default security group should be left as is - and users
> should be trained that they should bring/create security groups with the
> appropriate rules for their need.
>

+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160303/093493b3/attachment.html>