VMware vCloud Security: If you're familiar with Vmware vCloud, this is the book you need to take your security capabilities to the ultimate level. With a comprehensive, problem-solving approach it will help you create a fully protected private cloud.

Looking at a simple high-level cloud architecture, it might contain a VMware vCloud Director server or a group comprising of multiple vCloud Director servers. Each server can run a collection of services called a vCloud Director cell.

The following figure shows the vCloud architecture and depicts the core architecture and the optional components of vCloud. Though you can have multiple vCloud Director servers in a group, all the vCloud Director servers in the group share a single vCloud Director database. To provide resources for cloud tenants, vCloud Director (vCD) connects to one or more VMware vCenter Server systems and the VMware ESXi hosts.

VMware uses one VMware vCloud Networking and Security server for each vCenter Server instance, that is, the vCloud Networking and Security manager always has a one-to-one relationship with vCenter. vCloud Networking and Security servers provide network security services and deploy VMware the vCloud Networking and Security Edge devices (virtual appliances) on demand from vCloud Director to provide static routing, VPN, NAT, DHCP, gateway, and firewall services. This not only enables vCloud Director to provide multitenancy but also a provides a foundation for Software Defined Networking (SDN), which allows network connectivity that is programmable and decoupled from the physical infrastructure. Thus it enables workloads to be placed and moved anywhere.

vCloud Director uses vSphere to provide the CPU and memory to run virtual machines. For virtual machine networking, it uses vSphere's Distributed Switches and Standard vSwitch as well. However, the vSphere Distributed Switch must be used for cross-host fencing and network pool allocation. vSphere VMFS (Virtual Machine File System) datastores provide storage for virtual machine files and other files necessary for virtual machine operations. These underlying vSphere resources are used by vCloud Director to create cloud resources. This is depicted in the following figure:

vSphere clusters should be enabled with VMware vSphere Distributed Resource Scheduler (DRS) that should set to balance the vCloud Director deployed workloads across the physically compute resources of the vSphere DRS cluster. You can define a single cluster for the cloud provider resource or use multiple vSphere resource pools to provide the cloud provider resource. Though resource pools are supported, the best way to use them is in a cluster-wise format from a scaling perspective.

Let us take a closer look at the vCloud side. A vCloud Director Server group consists of one or more vCloud Director servers, which are also called vCloud cells. These servers share a common database and are linked to the vCenter Server systems and ESXi hosts. The vCloud Networking and Security servers provide network services for vCloud Director. If you want to segregate and allocate vCloud resources to the organizations, there is a web-based portal for vCloud administrators to do this. This web-based portal can be used for each organization as well and can provide consumers with the means to create and manage their own virtual machines. However, access is controlled through a role-based model set up by the organization administrator. A vCloud administrator has the ability to set the lease time to control how long vApps can run and be stored.

Let us look at the hybrid cloud scenario:

The following diagram gives an overview of this scenario:

vCloud administrators can also set quotas that limit the number of virtual machines that an organization can have, define an isolated or shared network, have complete control of the network flow, have preestablished pools of resources, and implement security policies. The following figure shows the vCloud components and the integration of them:

Other than the core vCloud components, you can also add other VMware components to increase the capabilities or control. One example is VMware vCenter Chargeback. vCenter Chargeback provides resource metering and reporting to facilitate resource chargeback. vCenter Chargeback comprises of the vCenter Chargeback server and vCenter Chargeback data collector. Though a Chargeback component is optional, it is a must to meet the NIST (National Institute of Standards and Technology) cloud computing definition. Another additional component is VMware vCloud Connector. vCloud Connector helps facilitate the transfer of a "powered-off" vApp in the Open Virtualization Format (OVF) format from a local cloud (this could also be vSphere) to a remote cloud or a vSphere instance. vCloud Connector is a virtual appliance that is installed in vSphere and handles all the logic of dealing with other clouds. The GUI is displayed in the VMware vSphere Web Client or the C# client through the vCloud Connector browser plugin.

vCloud management cluster is a VMware vSphere High Availability (HA) and vSphere DRS (Distributed Resources Scheduler) cluster that is created to manage a vCloud architecture. A management cluster contains the standard management components, such as ESXi hosts, vCenter Server system, vCloud Director cell servers, database server/s for vCloud Director, and vCenter. A management cluster should have its own shared storage that will store the virtual machines running inside the management cluster. The management cluster should also be separated into a single physical site. We would like to emphasize that for the cloud, it is a must to have a separate management cluster. It is a best practice to place the management components in a management cluster.

You should use vSphere HA and DRS on the management cluster to provide availability for all the management components. For vSphere HA, use the Percentage of Cluster Resources Reserved admission control policy in an n + 1 fashion instead of defining the amount of host failures a cluster can tolerate or specifying the failover hosts. This approach will help you to allow management workloads run evenly across the hosts in the cluster without the need to dedicate a host strictly for host failure situations. But this is not just limited to n + 1; for higher availability, you can add a host for an n + 2 cluster, although doing so is not a requirement of the vCloud private or public service definitions.

You may be wondering why you need a vCenter Server inside your vCloud management cluster. This management vCenter Server will carry clusters that will host cloud workloads. These resources are allocated by vCloud Director as a provider datacenters. Within a distinct vSphere cluster, a provider datacenter translates into a resource pool that is created automatically by vCenter, issued on a request from vCloud Director.

Although you can physically separate the management cluster and resource cluster, it is not a good practice to do so. You should put the management cluster and vCloud consumer resources on the same physical site. If you use a single site, it ensures a consistent level of service. Otherwise, latency issues might arise if workloads must be moved from one site to another.

Even before you start the installation of the vCloud, you should remember that this is a complex system and thus requires proper planning for the installation. If you choose the correct steps and choices, you can save a lot of time during the installation.

For installing vCloud Director, there are lots of prerequisites that have to be in place before you can proceed further. Let us look at those:

For more information, please see the VMware vCloud Director 5.1 Documentation Center at http://pubs.vmware.com/vcd-51/index.jsp.

VMware vCloud Director has been designed to be a really secured environment right from the bottom to the top layers. However, it is up to the vCloud Director administrators how they can use security roles, and the LDAP integration to keep VMware vCloud secure. However, this was based in vCloud Director Version 1.5.

The vCloud Director security guide is available at http://www.vmware.com/files/pdf/techpaper/VMW_10Q3_WP_vCloud_Director_Security.pdf, which covers in detail how to address the security needed for specific environments.

If you look at the vCloud Director Security model and see how a user can be identified, you will see that user identification can happen from five possible locations and those are:

System administrators have been defined at the system level, and they carry full system-level access.

As VMware vSphere, vCloud Director also uses roles and permissions to determine what actions a user can perform in an organization. vCloud Director comes with a number of predefined roles with specific rights. System administrators and organization administrators have the ability to assign each user or group a role. It is possible to have the same user imported into different organizations from one LDAP system. That user can then be assigned different rights in each organization if desired. System administrators can also create roles and modify existing ones. Also all the roles can be modified by the system administrator. They can also create custom roles.

By default, vCloud Director ships with some predefined roles and those are:

The main benefit of using LDAP is that you can use it to provide a directory of users and groups to import into an organization. Otherwise, you have to create a user account for each user in the organization. However, it is limited to the system administrator only, that says, an organization admin cannot modify this. A system administrator can set the LDAP in such a way that each organization will have its own LDAP configuration. They should import users and groups into the organization and assign roles before they can be used.

Another good part here is that with the release of vCloud Director 5.1, it supports importing users from VMware vCenter Single Sign-On. A Single Sign-on, also known as SSO capability, is where a user can have a single user ID and password that works throughout the system. vCloud Director provides SSO by integrating either LDAP or vCenter SSO identity. It is a system administrator's job to import users from LDAP or vCenter SSO as vCloud Director does not import users automatically.

vCloud Director does not import users' passwords from external LDAP systems. Instead, vCloud Director will confirm that a password is correct when a user logs in by checking the supplied hashed password against the hashed password currently stored in the LDAP directory.

vCloud Director has the ability to use LDAP at both the system level and the organization level. At the system level, you can either connect to an external LDAP system or create and use users who are internal to vCloud Director. You can use an external LDAP system to bring in users, but VMware recommends that you create at least one system user, which is only internal. The existence of at least one internally defined system administrator allows you to log in to your vCloud Director console even if the LDAP system is offline.

There are two ways to log in to the LDAP server. One is simple authentication and the other one is with Kerberos authentication. Simple authentication is, well, simple. However, Kerberos is a ticket-based system of client and server authentication. In Kerberos, both parties must prove their identity to each other. Kerberos uses symmetric key cryptography and can also leverage public key cryptography. If you are using Kerberos authentication, you must add a Kerberos realm to the vCloud Director Server first.

In order to use SSL, you must select it. You must then determine whether you will automatically accept all the certificates, or you will insist on browsing to a specific certificate. Using all certificates is much easier to configure. If your LDAP server has a certificate, it is accepted automatically. The use of SSL also provides an encrypted password exchange with the LDAP server. But the certificate from the LDAP server must be located on your system (the one the vCloud Director console is running from) and you must know the location of your SSL keystore file and have the password.

At the organization level, vCloud Director presents the following three options:

vCloud Director system administrators are authenticated by the vSphere identity provider when you use vCenter SSO. However, as a prerequisite, vCenter SSO must be configured in vSphere. vSphere Lookup Service must be registered in the vCloud Director Administration tab under Federation. vCloud Director should also be configured with the vSphere Lookup Service URL. vCloud Director system administrator users must be imported (either as a user or a group) from the vSphere identity provider. Only vCloud Director's system administrator users can be authenticated through vCenter SSO.

One of the most important factors for the overall system security is to record and monitor the activities of the users. The organization maintains their compliance with rules by maintaining an audit log of significant activities. Using audit logs, an organization verifies and detects any violations and initiates remediation activities.

Audit logs can also help the organization in detecting attempts, whether successful or not, to gain illegitimate access to the system, probe its information, or disrupt its operation.

VMware vCloud Director includes the following two types of logs:

As a vCloud system administrator, you can view the system log to monitor system-level tasks that are in progress. Also, you can find and troubleshoot failed tasks as well. You can also analyze vCloud Director logs to monitor vCloud Director cells.

As a vCloud organization administrator, you can view the log for an organization to monitor organization-level tasks that are in progress. In addition, you can find and troubleshoot failed tasks.

So essentially, we are talking about system-level and organization-level tasks.

vCloud Director provides logging information for each cloud cell in the system. You can view the logs to monitor your cells and to troubleshoot issues.

You can find the logs for a cell at /opt/vmware/cloud-director/logs.

The following table shows the log names and their purposes:

Apart from the diagnostics logs in the vCloud Director, you have audit logs mentioned in the preceding table as well. However, by default, these files are not forwarded to the centralized logging server. You have to manually configure the vCloud cell to forward these to the centralized logging server.

It is recommended that you configure this option for the following reasons:

In this chapter, we have installed VMware vCloud Director and performed a basic configuration of it. We have successfully installed and configured vCloud Director. Also, we looked into the basic security hardening aspects. We discussed basic security aspects of vCloud Director systems. This security aspect includes the user and different security roles, integrating different types of LDAP servers, and its options at various levels, which include the system level and the organization level.

In the next chapter, we will talk about VMware the vCloud Networking and Security App, and how we can integrate it to vCloud Director. We will also discuss the installation steps of the vCloud Networking and Security App, the vCloud Networking and Security App firewall management, and flow monitoring.