On 03/02/2016 01:53 PM, Andrew Laski wrote:
On Wed, Mar 2, 2016, at 02:36 PM, Gregory Haynes wrote:
Clearly, some operators and users disagree with the opinion that 'by
default security groups should closed off' given that we have several
large public providers who have changed these defaults (despite there
being no documented way to do so), and we have users in this thread
expressing that opinion. Given that, I am not sure there is any value
behind us expressing we have different opinions on what defaults
should be (let alone enforcing them by not allowing them to be
configured) unless there are some technical reasons beyond 'this is
not what my policy is, what my customers wants', etc. I also
understand the goal of trying to make clouds more similar for better
interoperability (and I think that is extremely important), but the
reality is we have created a situation where clouds are already not
identical here in an even worse, undocumented way because we are
enforcing a certain set of opinions here.
To me this is an extremely clear indication that at a minimum the
defaults should be configurable since discussion around them seems to
devolve into different opinions on security policies, and there is no
way we should be in the business of dictating that.
+1. While I happen to agree with closed by default there are many others
who feel differently, and there are cloud deployment scenarios where it
may not be the reasonable default.
It seems to me that visibility should be the primary focus. Make it easy
for users to know what they're getting, and make it clear that it's
something they should check rather than assume it's set a certain way.
++ And make it easy for them to choose the other thing.
(try writing an idempotent ansible playbook that tries to make your
security group look exactly like you want it not knowing in advance what
security group rules this provider happens to want to give you that you
didn't think to explicitly look for.)
Cheers,
Greg
____________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
