The Cart Before the Virtual Horse: VMware’s vShield/Zones vs. VMsafe API’s
Two years ago VMware announced their intention to develop and release a set of capabilities which would provide a more resilient and secure hypervisor while also extending a set of API’s to a limited number of vetted third-party security ISV’s.
These APIs were designed to regain visibility and add capabilities such as virtual introspection across compute, network and storage realms in order to solve some really difficult issues that I’ve spoken about extensively in my Four Horsemen of the Virtualization Security Apocalypse talks.
The reality is that VMsafe required two very important things to happen before it could see the light of day:
- A new version of VMware platform with a substantial overhaul of virtual networking capabilities and
- New versions of every ISV’s products who wish to take advantage of the API’s
Both of these things take substantial time and engineering effort and make for some very challenging integration, testing and product management challenges for both VMware and the security ISVs in the ecosystem. I’ve lived this life on both sides of the fence and it ain’t pretty folks.
Here’s the cool thing, although it’s arrived out of order, the integration of technology from the Blue Lane acquisition (with the IPS and patch proxy functions removed) adds the capability to provide for logical zoning and policy/firewalling enforcement and yields a very interesting side effect..
For all those vendors struggling with having to retool their virtual appliances and write kernel-level drivers for fastpath functionality in order to work with VMsafe API’s as well as their own slowpath drivers in the VA, vShield ultimately offers a solution that instead depends upon VMware’s dvFilters to redirect certain protocols to a virtual appliance based upon zones.
I saw a demo of how RSA has taken their DLP solution (from the Tablus acquisition) and by using vShield/Zones to provide for the filtering and agreeing on a comms. path between the VMM and the RSA virtual appliance, they can integrate their solution without having to re-write their code or develop fast path drivers!
Now, there’s a trade-off in extensibility because the capabilities of what are exposed are limited since VMware effectively controls that in this scenario; you might expect only fixed protocol redirection or some other prescribed limitation.
Regardless of how this plays out functionally, both ISV’s and customers now have an expanded choice when it comes to deciding how they might integrate security controls:
- Use VMsafe API’s but wait for a vendor to re-write their code, integrate and test and get the best balance of performance, extensibility and customization of the solution or
- Use vShield/Zones with shorter development and test cycles without having to modify their code. This offers potentially less optimized performance, less extensibility but again potentially less attack surface since API’s are not exposed and there is no third party code in the VMM.
vShield/Zones will help the security ISV’s integrate their solutions more easily and hopefully quicker and will give customers the CHOICE of the trade-off between security, performance and functionality in terms of security solution integration. It also means that the number and choice of ISVs in the ecosystem should expand.
Further, it may mean easier integration of security controls in Cloud scenarios as VMware extends vCloud.
I eagerly await more information regarding how vShield and the VMware/RSA proof-of-concept develops. I hope that the PoC generates interest and accelerates the delivery of security solutions from ISVs who may not have previously been able to participate in the VMsafe API program.
/Hoff
This is definitely a forehead slapper. The use of Zones as a shorter path, with potentially little or no refactoring (such as RSA's DLP solution) is quite cool.
My (admittedly limited) understanding of VMsafe does raise some questions, which you're much better prepared to address:
My take is that one of the big advantages of fastpath is the ability for multiple "taps" on the interaction between network and hypervisor to exist, with the inclusion of a hierarchy or interrupt level that helps avoid collision among different apps that are given access to fastpath. Do you have any sense as to the limitations on the sue of Zones to coordinate a number of appliances (e.g. more than one)?
Clearly, having only one possible would still be a big win. But unless there's a reasonable means of choreographing multiple pairings between the vShield filter and virtual appliances, this might be a very transitional use for Zones. Or, am I missing something?
– Rich
With VMsafe-NET there is a control plane for multiple vendors that doesn't require any underlying configuration, or other product, to be active in order to route traffic. Even if vShield could be used to route to multiple appliances, I would be concerned about how cleanly this could be configured.
VMsafe-NET also has built in first class support for VMotion allowing state and configuration to travel with the VM (assuming the destination has the same FP/Appliance). I realize you are dubious of the DRS argument based on your poll, and I would tend to agree, but even when using VMotion under vanilla circumstances like Update Manager its helpful if the overall configuration can be preserved.
Apani EpiForce has been providing logical zones for years now. One of the benefits of doing it outside of vShield Zones is that you can extend those zones outside of the VMware VME and across physical machines and other VMEs. It also has encryption based on very specific policy at the machine or user level, enabling companies to satisfy regulatory compliance without touching their existing physical or virtual networks.
grandioso a relumento si aticaires chenica con bagrisa. priamos istados se agnada son advencia mi rasso esseflo y enaco tizicatam omplilo.