vCloud Director Security Model

A few moments ago VMware announced their new Cloud Computing product, vCloud Director.  Yesterday I was able to attend a session dedicated to the security model of this product.  Vishal Kumar from VMware presented the concepts and did an excellent job.  This post is a bit of a brain dump based on how fast I could write down my notes so I may have missed a few things, my apologies for that.

If you are familiar with the design concepts of VMware's Lab Manager, think of vCloud Director as Lab Manager on steroids for production environments.  If you know Lab Manager, you will feel right at home in this product.  vCloud Director is designed from the ground up with secure multi-tenancy in mind.  The environment is achieved by providing a layer of abstraction above the existing VMware Virtual Center and vSphere resources.

Before I go any further, some definitions are needed:

Organization - This is essentially a tenant or a consumer of resources.  This could be different customer, departments, or any other group of people and resources that you would like to present computing capacity


Provider Virtual Data Center (vDC) - An aggregate pool of vSphere resources that represents the entire amount of capacity.  Think of this as an entire pie

Organization vDC - A subset of resources from the Provider vDC that are assigned to a specific organization.  Think of this as a slice (or slices from the pie)

vApps - A vApp is a group of virtual machines that represent a pre-configured grouping that can be delivered to a vCloud Organization.  This is what the Organization users will see.

Cell or Pod - An underlying group of Virtual Center servers and vSphere servers. vCloud Director is designed to scale horizontally by adding more Pods over time as needed.  There is currently a limit of 25 vCenters.

Based on all of this, you will have a nested structure that looks something like this:

As you can see, vCloud Director removes the VMware resources and provides objects that can be assigned to Organizations and users in a way that allows them to "help themselves" while at the same time isolates them from each other.

There are two ways to access vCloud Director as a consumer.  One is to use the built in GUI, the other is through the vCloud API.  I haven't seen the API in depth yet but I'm told it can serve as a complete replacement to the GUI for task automation or it can also provide an alternate GUI specific to your needs.

The security model of vCloud Director is based on a Role Based Access Control (RBAC) model.  RBAC roles and permissions can be assigned at both the top level (System or Cloud level) as well as the Organization level.  vCloud Director is also able to integrate with multiple LDAP directories at once in case your organization or customers use different LDAP resources.

Network security and isolation is very complex in this product and I'm actually attending sessions later in the week to get more information in depth.  I will present this as another post later in the week but here is a quick summary.  Network resources can be isolated through the concept of "fencing".  There is also a firewall product built-in called the vShield Edge device.  This device is a virtual machine and allows vCloud Director to provide both NAT and DHCP capabilities to vApps.  Syslog server support is also included in the product.

In summary, vCloud Director is a fully multi-tenant middleware with charge back, billing models, and service tiers integrated into the product.  I'm very excited to see what the future of vCloud Director holds!