vShield products packaging explained (with a focus on vCloud Director)

The way VMware is packaging / positioning vShield technologies isn't clear to everyone. This shouldn't be surprising since we have been lately expanding the offering with a lot of new stuff. In this post I am going (to try) to make a sense of vShield, its importance and specifically how it relates to vCloud Director. I am probably doing this in a non conventional way. At least in a way that a formal product manager wouldn't use.

vShield for Dummies

So what is this "virtual Shield"? Think of vShield as the go-to brand for all security things at VMware. At the time of this writing there are three major products under the vShield umbrella. They are vShield Edge, vShield App and vShield Endpoint. This is the high-level oversimplified view:

Let's try to get into more details. I want to break them down into pieces to describe what each of this pillars do. Remember I won't be using standard / corporate type of messages and definitions. Bear with me.

- vShield EndPoint is a "middleware for consolidated antivirus solutions" (i.e. install the AV engine once and protect all VMs on an ESX host). This builds on top of the VMSafe APIs we have announced a while back. Ideally the VMSafe APIs would allow third parties to hook in and build their security solutions. It turned out that for antivirus solutions this would have forced ISVs to develop pretty low level kernel modules which was clearly not these people's main business. So what we did is that we closed the gap between the "raw" VMSafe APIs and the software value these antivirus ISVs need to focus on. Now, with vShield EndPoint, they can way more easily develop centralized antivirus appliances to monitor all VMs running on the same host without the burden of coding low level infrastructure kernel modules against the VMSafe APIs. In other words EndPoint is not an antivirus, it's just a middleware that enables rapid development of centralized antivirus solutions from our ISV partners.

- vShield App is, using engineering words, "a firewall with infinite ports". Think a vSphere vDS (vNetwork Distributed Switch) with firewall logic built-in: that's vShield App (not to be confused with vApp: two totally different things). Using App you can actually take a number of VMs connected to the same vSwitch / PortGroup and create connection rules so that you can restrict how VMs talk to each other on specific IP ports and protocols. This is pretty innovative because usually you'd need to have two network segments (layer 2 segments or VLANs if you will) connected by a firewall to establish those rules. Here we are essentially "draining" that security logic directly into the vSwitch allowing you to create rules on a per vNic level on a "flat layer 2 network".

- vShield Edge is a virtual perimeter security device. To make a parallel, if vShield App provides the privacy you expect from the doors in your apartment, vShield Edge is really like the "armoured door to enter into the apartment". Edge is a layer 3 and above (virtual) device that basically shortcuts two vSphere PortGroups. The two PortGroups represent two layer 2 networks (typically 2 VLANs but not limited to that) and the role of Edge is to provide layer 3+ services. In fact being Edge a perimeter device it supports things on top of firewall functionalities. These things are for example, but not limited to, VPN, DHCP, and NAT capabilities. In other words with vShield Edge you protect the traffic that enters into the PortGroup whereas vShield App allows you to create security zones on the same PortGroup.

So now that we have slightly more details on what they do let's try to call out some of the features each vShield product includes:

A common misconception is that vShield Manager is another vShield product. In reality vShield Manager is the console that rules them all. Think of vShield Manager as the vCenter for all vShield products mentioned above (however vShield Manager is free). Another misleading concept is that vShield Zones is a separate product or pillar if you will. vShield Zones is really a subset of vShield App. As you can see in the picture above Zones includes the core basic firewall functionalities whereas App includes the features of Zones plus traffic flow monitor as well as the ability to group workloads in groups for easier segmentation of traffic (groups can also be standard vCenter group objects such as clusters, datacenters etc).

Mapping vShield security products to other VMware products

We said that vShield is the security go-to brand for VMware. So how do we map these security functionalities to VMware products that require specific and peculiar security functionalities? First of all remember that VMware sells these features as standalone security products for vSphere deployments. No brainer. However we are also bundling some of these security functionalities with other products when we see a need and a fit.

The technical/licensing mapping we are doing at the time of this writing is summarized in the picture below.

We thought that a consolidated AV solution would be a perfect fit and use-case for a centralized desktop solution. That's why we are bundling vShield EndPoint with VMware View (the Premier edition).

Similarly we thought that, due to the convergence trend of once distinct pillars such as servers, storage and network, we could give the vSphere administrator the ability to provide more clever workloads segmentation if we gave them a hypervisor based firewall tool. That's why we bundle vShield Zones with any vSphere version starting from Advanced.

Last but not least the whole idea of multi-tenant support associated to vCloud Director was a perfect fit to use vShield Edge as the security device protecting the "tenant". Perhaps now my old vCloud Director Networking for Dummies post makes a little bit more sense.

The bundles I am referring to here are primarily licensing bundles but they are also "technical bundles" where we are integrating the products we are putting together. Admittedly some bundles may be better integrated than others. Also consider that adding additional vShield functionalities to a given product (that is already bundled with a subset of vShield as per the above diagram) needs to be considered and evaluated on a case by case basis. For example upgrading a vSphere solution with vShield Zone to vShield App or even to include vShield Edge and vShield Endpoint functionalities is just a license upgrade and everything is still fully integrated. After all this is at the basis of being able to sell vShield products for all VMware deployments. On the other hand upgrading vCloud Director to use VPN and Load Balancing can be done by upgrading the license but these functionalities may not be fully integrated natively into vCloud Director. We'll explore this last point in more details below.

vCloud Director and vShield Edge Integration

As promised let's dive a little bit into how the vCD and vShield Edge integration work. To make a long story short we have implemented in vCD a number of API calls that talk to the vShield Manager that is in charge of deploying, configuring and managing the vShield Edge devices that are meant to protect vCD tenants. For the sake of information it must be said that we are not surfacing 100% of the configuration potential for NAT / DHCP / Firewall functionalities. There are certain things that can be done natively using the vShield tools but cannot be done via these vCD API calls. Having this said, these differences are more of an exception than the norm as we have implemented almost everything. The picture below shows a simplified view of this integration:

This is the end-to-end integration I usually pitch when talking about vCloud Director. That's how we achieve out-of-the-box self-service capabilities across the board for workloads deployments as well as security configurations. This doesn't mean that in a vCloud Director deployment you can't use anything else from a security perspective. It means that if you decide to use something else (be it another security virtual appliance or a traditional external firewall) you lose this out-of-the-box integration and you have to do things differently. And this is exactly what we need to do if we decide to enable the other Edge features that are not included with vCD. Namely VPN and (Web) Load Balancing. Simply put we haven't yet included in vCD the integration code that would allow a vCD admin or user to interact with these features from within the vCloud Director UI (or the vCloud APIs for that matter). So how do we deal with this? Once you have upgraded your Edge licenses to enable VPN and LB functionalities, there are actually two ways of dealing with the fact that there isn't an out-of-the-box integration. The first one is what I referred to as the "ticket-based configuration". Basically the consumer of the cloud opens a "ticket" with IT so that IT can go and do the change (via the vShield Manager UI or the vShield Manager APIs) on the Edge device on behalf of the end-user. The advantage of this model is that there isn't any development effort on the provider side to integrate this functionality, the drawback is that this doesn't give the end-user a true self-service experience. The following picture shows this concept.

The other option is what I refer to as the "self-service-based configuration". This requires the provider to create a custom portal that includes both the vCD functionalities as well as the advanced vShield Manager functionalities so that the end-user has a single interface that can use to configure workloads as well as security (possibly including VPN and LB). It goes without saying that this solution gives a great user experience to the consumer looking for unmanaged services (do-it-yourself) but requires a certain amount of effort to create this portal "overlay". The picture below shows this second option.

If I say that we are certainly looking into expanding our own overlay of the vShield Edge functionalities I think I am stating the obvious (without breaking any NDA). I can't obviously say anything regarding when and how we are going to do that. Also if you are looking into using vShield App in a vCloud Director context some limitations on the network configurations may apply but, overall, the integration strategies aren't different compared to what I have described above for VPN and LB.

I hope this post gave you a rough idea of what the vShield brand is, how vShield maps and is related to other VMware products and last but not least how vCloud Director uses and integrates with vShield Edge. There are many details I have omitted here simply because I wanted to post something that could be easy to read to get an idea of where vShield fits into the big picture we are building. at VMware.

Massimo.