At VMworld 2008 VMware introduced a new way for protecting virtual machines. Previously anti-virus, firewall, file integrity and malware protection had to be performed at the virtual machine level by installing an agent.
With the introduction of the VMsafe.API network traffic can be now intercepted at the hypervisor level and inspected by a virtual appliance.
The VMsafe.API is used by selected number of third party vendors. However VMware announced in 2013 the end of life for the VMsafe.API. Customers wishing to continue agentless solutions might be facing high costs when upgrading to the vSphere 2015 release which is scheduled to replace vSphere 5.5 .
Introduction to agentless security
A traditional security agent installed in a virtual machine has a couple of disadvantages:
- consumption of resources. Each agent in each guest consumes compute, memory and storage resources. Imagine a situation where each anti-virus guest performs a scheduled scan on viruses at the same time. This will result in many storage IO. These scanning storms are not a nice situation for VDI.
- many virusses try to disable the anti-virus agent. By not using an agent but using technology in the kernel instead a much safer protection is created.
- powered off guests cannot be protected by using an agent but they can be infected .
VMware announced at VMworld Europe 2008 the VMsafe API. Basically the API allows inspection of network traffic at the hypervisor level. Network traffic can be intercepted after entering the physical network interface in the ESX(i) host. It is then routed to a vendor appliance. The appliance does the actual scanning on virusses and malware instead of the traditional deployment where agents are used in each virtual machine.
Agentless is not completely true. While an anti-virus agent is not installed in the guest, you still need to install a vShield agent. (thin agent)
This image below shows the flow of network traffic when VMsafe.API is used. The image is published at Rational Survivability.
After a rather slow adoption during the next years vendors started to support the API. Trend Micro was the first vendor to use VMsafe API for protection against virusses. Later McAfee joined supporting VMsafe with their MOVE product. Kaspersky Security for Virtualization also uses the API.
Juniper Firefly uses the API for firewall purposes like some other vendors.
To use the VMsafe API a seperate VMware product called vShield Endpoint needs to be installed. Initially vShield Endpoint inclusion was limited to the more expensive editions of vSphere. Alternatively vShield Endpoint could be purchased. At the release of vSphere 5.1 VMware made vShield Endpoint available for free for vSphere Standard Edition and higher.
It looked like VMware was promoting agentless solutions.
In 2013 VMware announced it will no longer support the VMsafe API in ESXi 5.5 . See this KB article titled ‘End of Life support for VMsafe and Partner Solutions using VMsafe on vSphere 5.5 (2058911)‘ for the details. Trend Micro and other vendors stated they will continue supporting the API in vSphere 5.5. To be able to use Trend Micro Deep Security in vSphere 5.5 and to get full Trend Micro support , customers have to use Deep Security version 9 Service Pack 1, PAtch 2.
While in vSphere 5.5 using VMsafe.API is still possible, the next release of vSphere, likely to be named vSphere 6.0, VMsafe.API is no longer included in the kernel of ESXi. VMsafe.API is being replaced by the VMware NSX API (formery known as the NetX API).
Customers wanting to continue to use agentless security solutions for vSphere 6.0 are likely required to adopt the VMware NSX for vSphere platform.
This raises some questions. NSX is targeted at large enterprises and service providers. It is a network virtualization tool which uses central management for provisioning and configuration of networks. NSX is not for the masses; it can only be sold by a limited number of certified VMware partners called NSX Elite partners. It is not available for public download. Organizations interested in purchasing NSX will have to do a paid Proof of Concept. The PoC will be built by VMware PSO staff.
NSX is also not a cheap extra license on top of vSphere. The list price is almost 5000,- or $5,996 per CPU.
VMware partners are not happy about replacing the VMsafe.API with the NSX.API. This API offers less features as documented in this article.
Some vendors prevent using VMware API or hypervisor based agents. For example InMage, recently acquired by Microsoft, uses agents in guest for replication. They state here:
Some vendors run an agent in the hypervisor for replication. Problem is that when vSphere 5 came out VMWare broke that connection for other ISV’s. VMware knew in vSphere 4 that they had a heterogeneity problem and needed storage replication. SRM’s failover and failback used to be a framework product to run on array replication. Since VMware is not open source the company does what is in THEIR best interest and put replication in the hypervisor and still supports array based replication. This took off value for other ISV’s because they now were locked out from providing that feature.
So what do you expect when high volume products don’t use open source or standard API’s? Unless that is their business strategy companies have no obligation to maintain standards. If you try to go into the vSphere and use a link such as VMSCSI you have no assurance that VMware won’t make changes that will break the software without notice.
At the moment nothing is known about what will be the cost for customers wanting to upgrade to vSphere 6.0 while continue to use agentless security solutions like Trend Micro Deep Security.
A possibility is that a limited edition of NSX will become available which provides the NSX.API functionality to third party solutions. VMware will shoot itself again it the foot (remember vTAX) when requiring their customers to purchase the full VMware NSX for vSphere SKU just to use agentless security solutions. Also their partners will not be happy with this possible move.
