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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
