Safely implementing VMsafe-aware virtual appliances in your data center

VMsafe-aware virtual appliances can subject a virtualization environment to security risks, but smart administration can help you avoid a breach.

VMware VMsafe is now available with VMware vSphere 4, but how it is implemented is not widely known. VMsafe is an application programming interface to protect applications running in virtual machines.

Granted, there are not many VMsafe-aware products but before you implement one -- including the Cisco Nexus 1000V virtual switch -- you should be aware of how to best integrate this technology into your data center for the best virtualization security, efficiency and performance.

In this tip, we discuss how to implement VMware VMsafe by considering the location of VMsafe-aware virtual appliances, the impact of these appliances on your hosts and interoperability issues.

Fast Path and Slow Path
VMsafe applications can come in two forms. The first form is referred to as Fast Path and is composed of just a vmkernel driver that gets installed on the VMware vSphere ESX 4 host. Fast Path has many advantages but only so much really belongs in a driver, and the driver is often used to further transfer necessary information to a virtual appliance. The combination of virtual appliance and vmkernel driver composes the second form, which is known as the Slow Path.

Because more VMsafe-aware applications use virtual appliances, it is important to consider the locations of these appliances within your data center. And from a security perspective to fully understand the implications of using a VMsafe appliance and its location within the virtual data center is critical. A VMsafe-aware virtual appliance has unprecedented access into the data structures that live within the hypervisor. This includes access to all reads and writes to memory, storage or the network. In some cases, a VMsafe-aware virtual appliance can change what is read or written to memory, storage, or the network.

This access is a major security concern. If you virtual appliance lives within a hostile environment such as a demilitarized zone (DMZ) or has direct access to the Internet, it is at risk for attack. A successful attack could be catastrophic to the security of your virtualized data center.

The first consideration when using a VMsafe-aware virtual appliance is that VMware vSphere does not automatically secure this appliance. It leaves the security of any appliance to you and the vendor. While the vendor will do its best, the security of VMsafe-aware virtual appliances is your responsibility.

Here are some general rules of thumb:

  • Do not place VMsafe-aware appliances within your DMZ.
  • Do not give them direct Internet access; go through a proxy service.
  • Do not place them on your virtual machine networks.
  • Do not place them on your service console and IP storage networks.
  • Do not place them on your VMware VMotion or Fault Tolerance logging networks.

So where can you place these virtual appliances?

  • Behind an appropriate firewall within its own security zone. Such a security zone could be part of your virtualization management network zone, or it could be in a separate security zone.

With the introduction of VMsafe, VMware has in effect implemented another security zone within your virtual network. An Enterprise/Enterprise Plus fully-enabled VMware vSphere ESX host now has six basic security zones, an increase from four that were common in VMware Infrastructure 3 (VI3). For some, this increase means making more less-than-desirable virtual networking choices.

In VI3, the common understanding was that the VMotion and service console could share the same uplinks, but we also now need to consider whether VMsafe can also share the same uplinks. Or should the combinations now be Service Console with VMsafe and VMotion with Fault Tolerance Logging? The answer will mostly depend on your usage scenarios and performance.

VMsafe and virtual machine performance
Depending on function, VMsafe-aware appliances can be resource-intensive virtual machines. For example, if you want full, deep-packet or memory analysis, your VMsafe appliance will be performance-sensitive. In other words, its processing will affect the performance of the entire virtual environment running with the ESX 4 host. Full deep-packet and memory analysis is a CPU-intensive process that also needs to be considered.

The last consideration is the interaction between multiple vendors' VMsafe vmkernel drivers. If you plan on using multiple VMsafe products you will have to vet and test each vmkernel driver for interoperability issues. VMware will not test these interactions, and vendors may not either. But since they are third-party vmkernel drivers, they could pose interoperability issues.

When you start to implement VMsafe appliances, you need to be careful. And the Cisco Nexus 1000V is a VMsafe appliance. Consider carefully where to place each VMsafe-aware virtual appliance. Consider an appliance's impact on your VMware ESX 4 host. And finally, consider interoperability issues. Plan, test, and evaluate before implementing VMsafe within your production virtualization hosts.

 

Edward L. Haletky is the author of VMware ESX Server in the Enterprise: Planning and Securing Virtualization Servers. He recently left Hewlett-Packard Co., where he worked on the virtualization, Linux and high-performance computing teams. Haletky owns AstroArch Consulting Inc. and is a champion and moderator for the VMware Communities Forums.


 

This was first published in July 2009

Dig deeper on VMware basics

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchServerVirtualization

SearchVirtualDesktop

SearchDataCenter

SearchCloudComputing

Close