Hello Neutron Team,

I'm part of a company that is currently migrating from homemade

software to manage the infrastructure for a virtualization-based

product towards an openstack based infrastructure.

As such, this platform includes both private and public cloud usages,

which brings me to our current network problem.

Essentially, as administrators of the system, we want to expose a

pre-configured network, which provides access to some non-openstack

 managed resources, via some routing mechanisms.

The various VMs on this network must not be able to see each-other,

as this network may be exposed to multiple customers/projects.

Note that in this context, we're using the OVN driver for our network stack.

We were initially looking at external networks for this, but understood

through our attempts and experimentations that:

 - External networks are shared to all projects by default

 - Default sharing of external networks can be disabled by removing the

   automatically injected rbac for '*', allowing us to expose the network to

   only the projects we specify

 - VMs on this network can communicate with each other

     - Applying FlowControl does not solve this for VMs on the same

       Hypervisor (as they're directly communicating, and traffic does not

       seem to go through the host)

     - Only security groups can prevent such communication, but since it's

       associated to a Port, we cannot enforce it

  - All flow control for the various networks connected to a VM are currently

    setup on a single bridge interface on the hypervisor

First question is simple:

Did we miss anything ? Or is our understanding of the mechanisms on point ?

In the second case, this leads me to the proposal mentioned in the subject:

Offer a Network/SecurityGroup binding mechanism that would

 automatically/implicitly include its rules to the port's rules.

The idea is that this would allow an administrator (and project administrator?)

to enforce specific rules via security groups attached to the network itself,

effectively providing a category of network  aimed at providing connectivity

to a specific external service.
Additionally, this creates a behavior where unless the administrator allows it,

no two VMs on this network may be able to communicate together, as a default.

What do you think about this feature ?

Is there any major risk/flaw that I might be missing ?

Would you, as a community, welcome such an effort ?

Kind regards,

--

David Pineau

Engineer @Shadow

IRC nick: joa