Isolation in Advanced Zone using PVLANs
1 Background
Isolation of VM Traffic is achieved using Security Groups in Basic Zones. For Advanced zone, traffic can be isolated on a per network basis using VLANs. Advanced Zones support shared as well as isolated networks. Currently, there is no way to isolate guest traffic within a network. There is another similar requirements document for SG support in advanced zone for XS and KVM.
Another way of supporting isolation within a guest network is using PVLANs. This requirements document captures the requirement related to adding PVLAN support. For VMWare Hypervisor, since the classic SG support can't be added, one of the solutions would be to support PVLANs (Private VLANs) for this solution.
Customers / Users have asked for the following requirements across all Hypervisors.
Use Cases:
- Isolation within a network: Shared Networks can be created with different levels of scope. It can be shared within an account, domain, project or a global shared network. With multiple users deploying VMs on a shared network, users might want to control traffic on their VMs based on Security groups.
- Isolation across multiple networks: Some customers might deploy multiple shared networks and they might need to restrict communication not only within a network but also across different networks. For example, user A could have VM1 in Network 100 and VM2 in Network 200 but they might want to limit the communication on these VMs to just talk to each other and a limited set of Public IP Addresses.
- VMs deployed using multiple Networks: There could be various cases in which a VM is deployed on two networks (an isolated network for the account and a common shared network providing monitoring capabilities). In these cases, admins will want to limit the communication between different tenants who are sharing the common shared Network.
- Isolated Network: With Isolated Networks (including VPC), users can deploy multiple applications on the same isolated Network or same VPC. Users might want to prevent communication between the applications within the same Network/VPC.
The most common requirement is for customers to run multiple Shared Networks to offer various services like monitoring, patching, etc. Although, not all of the requirements can be met with PVLAN support, this basic requirement could be addressed with CS enabling the PVLAN support.
Customer Benefits:
- Allowing users to control traffic within a network would help them deploy multiple applications without communication between application as well as prevent communication with other users’ VMs.
2 Requirements
- Most important requirement is to isolate VMs from other VMs on the same network (Shared Networks are the most common use case) using PVLANs
- Allow admins to create a Network Offering enabling PVLAN support
- Allow admins to create shared networks based on a network offering which has PVLANs enabled
- Admins would have to configure PVLANs on physical switches out-of-band
- Feature needs to be supported in VPC as well as non-VPC deployments
- Support for this functionality should be provided on all Hypervisors (unless SG support is added for KVM and XS which is tracked by another feature requirement)
- Allow end users to deploy VMs on Isolated Networks or VPC along with the Shared Networks that have PVLAN support
- UI support needs to be added for this feature
- The UI workflow should be same irrespective of Hypervisor
4 Upgrade Scenarios
There are no upgrade requirements as this would be a new feature.
5 Non-Requirements
- As part of PVLAN support, customers would also need to configure their physical switches for PVLAN configuration. For the first phase, it can be assumed/documented that the providers would configure PVLANs on Physical switches out-of-band.
6 Bugs
7 References: