Open Stack

Hi,

I understand that it's more user-friendly to enable by default all traffic
to VMs,
but it seems clearly unsecure to enable by default all traffic to VMs
(including ssh from internet!!!),
as it increases the VM exposition surface on internet and reduces its
security.



Cédric/ZZelle




On Tue, Mar 1, 2016 at 11:52 PM, 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?
>
> Second, would it be acceptable to make this operator configurable? This
> would mean users could receive different default filtering as they moved
> between clouds.
>
>
> Cheers,
> Kevin Benton
>
> __________________________________________________________________________
> 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/20160302/7b156703/attachment.html>