Bug 1474823
| Summary: | [RFE] Require a feature similar to private VLAN for instance ports / admin security groups | |||
|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Andrew Ludwar <aludwar> | |
| Component: | openstack-neutron | Assignee: | OSP Team <rhos-maint> | |
| Status: | CLOSED WONTFIX | QA Contact: | Toni Freger <tfreger> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 10.0 (Newton) | CC: | dhill, dholler, gprocunier, mtomaska, nyechiel, srevivo, vkoul | |
| Target Milestone: | --- | Keywords: | FutureFeature, Reopened | |
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | All | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1752343 (view as bug list) | Environment: | ||
| Last Closed: | 2023-10-11 19:20:01 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1752343 | |||
|
Description
Andrew Ludwar
2017-07-25 13:13:29 UTC
I don't see enough demand for such a feature and realistically this is not going to be implemented by Red Hat any time soon. Please re-open if you think otherwise. *** Bug 1752343 has been marked as a duplicate of this bug. *** We are interested in configuring a shared services L2 network used by manila to prevent cross tenant backdoors (In OSP13 and onwards).
Eg.
Manila-NFS-VIP
192.168.103.4
|
SharedNFS Network
(192.168.103.4/24)
/ \
Tenant A Tenant B
| |
SharedNFS Port SharedNFS Port
192.168.103.10 192.168.103.20
| |
Instance Instance
| |
Internal NIC Internal NIC
172.16.0.50 192.168.20.20
If openstack neutron/ovn supported PVLAN we could configure the uplink of the tenant nic on that network to be exclusively the Manila-NFS vip and stop any potential of backdoor access from other clients on that network.
In my diagram you can see that the storageNFS network is a shared layer 2 domain. At no point can we assume that tenants will do the right thing with regards to security groups.
PVLAN solves this issue by preventing isolate ports from learning about each other, and the destination (in this case the NFS ganesha vip) is set in promiscuous mode.
This is a diagram of PVLAN operation from Cisco:
https://www.cisco.com/c/dam/en/us/td/i/100001-200000/180001-190000/182001-183000/182773.eps/_jcr_content/renditions/182773.jpg
This is the actual writeup by Cisco on this capability: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/6-x/layer2/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Layer_2_Switching_Configuration_Guide/b_Cisco_Nexus_9000_Series_NX-OS_Layer_2_Switching_Configuration_Guide_chapter_0101.html#con_1344155
I spoke with Tom Barron (Manila PTL) and Ryan Tidwell (Neutron Developer) and they both agreed this was a problem that PVLAN could solve. As Symcor is looking to leverage OpenStack with Manila across a multi tenant environment we want to be able to provide high performance Layer 2 access to our StorageNFS network without the security backdoors a regular layer 2 domain creates.
Implementing PVLAN in neutron would certainly help our use of the product and also add some fairly powerful capabilty to OpenStack.
|