Open Stack

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.

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

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

This one really rubs me the wrong way. Can we please get a better
description of the bug - instead of someone just saying that Neutron
doesn't work, therefore we don't want any filtering or security for our
instances using an 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.

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?

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.

If infra wants to opt out of the security group API and allow
everything, and then filter using the guest - then fine. That's their
prerogative. All they've done is change where their security policies
are implemented. Instead of a REST API they want to do it directly on
their guest.

-- 
Sean M. Collins