I have been thinking about blades and virtualization security for some time spurred on by a conversation with Brad Hedlund six months ago. Nearly all my customers use Blades and virtualization security is a big concern to them. In my Rethinking vNetwork Security article, I touched on some of the issues in response to Brad’s comments a while back. I would like to now expand that discussion to blades.
There are three sets of blade enclosures I would like to discuss, those that use pass thru networking, those that use standard switching fabric within the enclosures, and those that use flexible interconnects such as HP Flex-10 and Cisco Palo adapters. The last is the so called physical-virtual network device.
I presented similar figures in the Rethinking vNetwork Security article that cover the case of pass thru and normal switching fabric based blades. Figure 1, on the other hand looks at blades from the perspective of the physical virtual network device. In this case, you can see that within the vmkernel or hypervisor the similar split is done, BUT instead of going to the outside, the Blade MidPlane comes into play. Figure 1, shows two blades connecting to the same Midplane and therefore the same pvSwitch control plane.
The Blade MidPlane is where the flexible or physical-virtual devices live. While Blade MidPlane can have any number of interconnects such as pass thru, physical switches, and physical virtual switches (pvSwitch). We are concerned with the pvSwitch here.
In essence the mezzanine card within the blade acts in concert with the pvSwitch to provide a set of networking devices to the vmkernel that can be attached to any number of physical virtual port groups (pvGoup).Â The pvSwitch Control Plane is used to manage these groups and if VLANs are assigned, the VLANs as well. If the pvGroup also uplinks to an external source, such as another blade enclosure or an external pSwitch, then the pvGroup is no longer private to the pvSwitch. From a technical perspective, pvGroups work just like VLANs, but unless there is a VLAN associated with them, the traffic may not be restricted to just that group. This depends on the type of pvSwitch in use. In the case of the HP Flex-10 device, a pvNIC (on the mezzanine card) is connected to a pvGroup that is private to the pvSwitch unless there happens to also be an uplink involved regardless of VLAN usage.
What does this all mean? It means that the logical separation achieved by using multiple vSwitch types (such as the VMware vSwitch, Distributed Virtual Switch, and Cisco Nexus 1000V or N1KV) could be lost once you use a blade, depending on the blade interconnect chosen. Why? Because everything that you logically separated within the hypervisor once more joins together within the blade.Â So the choice of interconnect becomes very important from a security perspective. You need to understand the impact and workings of the interconnect to properly secure your environment.
The key questions are:
- Does the pvGroup provide separation with or without the use of VLANs?
- Does the pvSwitch Control Plane provide any other inherent protections?
- Does uplinking between blade enclosures provide the necessary segregation of data from other uplinks?
- How do you achieve redundancy using pvSwitch’s and pvNICs?
- What other special security features exist?
Ask these questions and plan out your environment properly to account for flexible or converged networking within blade enclosures so that the physical-virtual components are also part of this plan. A few companies consider the physical-virtual components to be the realm of virtualization while others consider them to be the realm of the traditional networking teams. Either case, you must consider them from a virtualization security view.