yahoo-eng-team team mailing list archive

[David Pineau <2075958@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

In the context of my work, I'm looking to "enforce" some security groups
settings onto all ports of a Network.

For a bit more context, we're configuring a network as external, so that it may provide network access to a service which is not managed by Openstack. We wanted, through this network, to allow only specific projects to access said service, with the following specificities:
 - Open access to said service by default (see RFE https://bugs.launchpad.net/neutron/+bug/2075955)
 - Prevent Each VM on this network from seeing each other, so that "exposing" the service to the VM does not inadvertently provide connectivity between the VMs

As we need to prevent each VM on this network (from possibly multiple
customers/projects, and even more end-users) from seeing each other, we
must prevent said projects/users from further opening the network for
their VMs. This leads us to a few ideas, as we have no idea what would
better fit the current neutron design and expectations:

  1. Add a new RBAC "action", either to allow or forbid associating SecurityGroups to the Network or the Ports created from it.
  2. Add a new Network/Port setting to determine who (owner/project-admin/member) can do what (create, delete, bind..) on security groups (or more entities if deemed useful)
  3. Simple flag to prevent anyone other than Admin from binding security groups to any entity related to this network (hackish version of 1 ?)

Of course, we're going to put in the work for this, as it's part of our
priority items, hopefully as part of a neutron contribution, if we find
a solution to this issue we can agree on.

** Affects: neutron
     Importance: Undecided
         Status: New

** Description changed:

  In the context of my work, I'm looking to "enforce" some security groups
  settings onto all ports of a Network.
  
  For a bit more context, we're configuring a network as external, so that it may provide network access to a service which is not managed by Openstack. We wanted, through this network, to allow only specific projects to access said service, with the following specificities:
-  - Open access to said service by default (proposal for this on https://bugs.launchpad.net/neutron/+bug/2075955)
-  - Prevent Each VM on this network from seeing each other, so that "exposing" the service to the VM does not inadvertently provide connectivity between the VMs (another RFE may address this, to be created)
+  - Open access to said service by default (see RFE https://bugs.launchpad.net/neutron/+bug/2075955)
+  - Prevent Each VM on this network from seeing each other, so that "exposing" the service to the VM does not inadvertently provide connectivity between the VMs
  
  As we need to prevent each VM on this network (from possibly multiple
  customers/projects, and even more end-users) from seeing each other, we
  must prevent said projects/users from further opening the network for
  their VMs. This leads us to a few ideas, as we have no idea what would
  better fit the current neutron design and expectations:
  
-   1. Add a new RBAC "action", either to allow or forbid associating SecurityGroups to the Network or the Ports created from it.
-   2. Add a new Network/Port setting to determine who (owner/project-admin/member) can do what (create, delete, bind..) on security groups (or more entities if deemed useful)
-   3. Simple flag to prevent anyone other than Admin from binding security groups to any entity related to this network (hackish version of 1 ?)
+   1. Add a new RBAC "action", either to allow or forbid associating SecurityGroups to the Network or the Ports created from it.
+   2. Add a new Network/Port setting to determine who (owner/project-admin/member) can do what (create, delete, bind..) on security groups (or more entities if deemed useful)
+   3. Simple flag to prevent anyone other than Admin from binding security groups to any entity related to this network (hackish version of 1 ?)
  
- 
- Of course, we're going to put in the work for this, as it's part of our priority items, hopefully as part of a neutron contribution, if we find a solution to this issue we can agree on.
+ Of course, we're going to put in the work for this, as it's part of our
+ priority items, hopefully as part of a neutron contribution, if we find
+ a solution to this issue we can agree on.

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2075958

Title:
  [RFE] Limit who may bind security groups

Status in neutron:
  New

Bug description:
  In the context of my work, I'm looking to "enforce" some security
  groups settings onto all ports of a Network.

  For a bit more context, we're configuring a network as external, so that it may provide network access to a service which is not managed by Openstack. We wanted, through this network, to allow only specific projects to access said service, with the following specificities:
   - Open access to said service by default (see RFE https://bugs.launchpad.net/neutron/+bug/2075955)
   - Prevent Each VM on this network from seeing each other, so that "exposing" the service to the VM does not inadvertently provide connectivity between the VMs

  As we need to prevent each VM on this network (from possibly multiple
  customers/projects, and even more end-users) from seeing each other,
  we must prevent said projects/users from further opening the network
  for their VMs. This leads us to a few ideas, as we have no idea what
  would better fit the current neutron design and expectations:

    1. Add a new RBAC "action", either to allow or forbid associating SecurityGroups to the Network or the Ports created from it.
    2. Add a new Network/Port setting to determine who (owner/project-admin/member) can do what (create, delete, bind..) on security groups (or more entities if deemed useful)
    3. Simple flag to prevent anyone other than Admin from binding security groups to any entity related to this network (hackish version of 1 ?)

  Of course, we're going to put in the work for this, as it's part of
  our priority items, hopefully as part of a neutron contribution, if we
  find a solution to this issue we can agree on.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2075958/+subscriptions