This checklist summarizes the key security configuration tasks described in this document.

  • In addition to the guidance in this document, you should monitor the security advisories at http://www.vmware.com/security/advisories/ and sign up for email alerts using the form on that page. Additional security guidance and late-breaking advisories for vCloud Director will be posted there.
  • Administrators should apply the steps recommended in vSphere Security (https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.security.doc/GUID-52188148-C579-4F6A-8335-CFBCE0DD2167.html), Securing VMware NSX for vSphere (https://communities.vmware.com/docs/DOC-27674), and the NSX-v 6.3.x Security Configuration Guide (https://communities.vmware.com/docs/DOC-28142) to ensure that they have secure installations of those products.
  • Apply current security patches to the cell Linux platform, vCloud Director database, and virtual infrastructure before installation; ongoing monitoring to keep these components at a current patch level is also crucial.
  • Standard security hardening procedures should be applied to the cell Linux platform, including disabling unnecessary network services, removing unnecessary packages, restricting remote root access, and enforcing strong password policies. Use if possible a centralized authentication service such as Kerberos. Consider installation of monitoring and intrusion-detection tools.
  • It is possible to install additional applications and provision additional users on the cell Linux platform, but it is recommended that you do not do this. Widening access to the cell OS may decrease security.
  • Make the responses.properties file available only to those who have a need for it. When it is in use (while adding cells to a server group), place appropriate access controls on the location accessible to all target hosts. Any backups that are made should be carefully controlled and also encrypted if your backup software supports that. Once the software is installed on all server hosts, any copies of the responses.properties file in these accessible locations should be deleted.
  • The responses.properties and global.properties files are protected by access controls on the $VCLOUD_ HOME/etc folder and the files themselves. Do not change the permissions on the files or folder.
  • Physical and logical access to the vCloud Director servers must be strictly limited to those with a need to log in and only with the minimal levels of access required. This involves limiting the use of the root account through sudo and other best practices. Any backups of the servers must be strictly protected and encrypted, with the keys managed separately from the backups themselves.
  • For database security requirements, please refer to the security guides for your chosen vCloud Director database software.
  • The vCloud Director database user should not be given privileges over other databases on that server or other system administration privileges.
  • Ensure that any credentials used for administrative access to the cell, the connected vCenter Servers, the vCloud Director database, to firewalls and other devices follow standards for password complexity.
  • It is important from a defense in depth perspective to vary the administrative passwords for the different servers in the vCloud Director environment, including the cells, the vCloud Director databse, vCenter Servers, and NSX.
  • See https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.security.doc/GUID-779A011D-B2DD-49BE-B0B9-6D73ECF99864.html for information about creating and replacing certificates used by vCenter and ESXi. This is highly recommended.
  • vCenter certificates should have a common name (CN) field that matches the FQDN (Fully Qualified Domain Name) of the server on which vCenter is installed.
  • Configure vCloud Director to Check vCenter Certificates.
  • vCenter Certificates should be signed by a CA and have a CN matching the FQDN of the host on which the cell is installed.
  • The recommended approach to making vCloud Director services available to the outside is to place the cells in a DMZ, with a network firewall separating the Internet from vCloud Director cells on the DMZ. The only port that needs to be allowed through the Internet-facing firewall is 443/TCP.
  • As the vCloud Director cells are in the DMZ, their access to the services they need should also be mediated by a network firewall. Specifically, it is recommended that access to the vCloud Director DB, vCenter Server, vSphere hosts, IDPs (including LDAP), and any backup or similar services be on the other side of a firewall that separates the DMZ from the internal network.
  • Virtual machines that require access from outside the cloud (for example, from the Internet) would be either connected to a public network or a private NAT-routed network with port forwarding configured for the exposed services. The External Network to which these organization VDC networks are connected would require a protecting firewall that allows in agreed-upon traffic to this DMZ network.
  • In general, it is recommended that vApps that need accessibility from the Internet be placed on a private, routed network. This provides the tenant control over firewall and port forwarding rules provided by NSX. These and other rules may be applied by default by the network firewall you choose to deploy. See your firewall's documentation for specific configuration instructions and default capabilities.
  • A defense-in-depth doctrine requires that JMX (port 8999/TCP) and JMS (ports 61611/TCP and 61616/TCP) be blocked at the network firewall that protects the DMZ to which the cells are connected.
  • To set the public Web URL, public console Proxy Address, and public REST API Base URL for a multicell cloud behind a WAF or load balancer.
  • A Web Application Firewall (WAF) should be deployed in front of the vCloud Director cells.
  • In such deployments, it is recommended that the WAF be configured so as to allow inspection and proper blocking of malicious traffic. This is typically done with TLS or SSL termination.
  • When configuring TLS or SSL termination, it is important not only to install a CA-signed certificate at the Web Application Firewall (WAF) so that client applications of the vCloud API and the Web console can be assured of the identity of the server, but also to use a CA-signed certificate on the cells even though they are only seen by the WAF.
  • Finally, if the load balancer is independent of the WAF, it too should use a CA-signed certificate.
  • It is recommended that you enable generation of the X-Forwarded-For header at the firewall if possible.
  • If the vCloud Director server has a third IP address assigned exclusively for management, bind JMX directly to this IP address. By default, the vCloud Director JMX connector binds to the primary IP addresses specified during configuration. This default can be overridden by inserting the following property in /opt/vmware/vcloud-service-director/etc/global.properties: vcloud.cell.ip.management=IP or hostname for the management network to which the JMX connector should bind.
  • The recommended and more secure configuration involves binding the JMX connector to the localhost address: vcloud.cell.ip.management=127.0.0.1. If JMX is only exposed to localhost, then securing JMX communications is accomplished through the use of SSH as a tunneling mechanism for any access to JMX. If your management requirements do not allow the use tis sort of localhost configuration and JMX must be exposed outside the vCloud Director server, then JMX should be secured with TLS or SSL.
  • Behind the cells are the private management elements required by vCloud Director: its database, NSX, vCenter Server, the system LDAP server, if any, the Active Directory server used by vCenter, and the management interfaces of the vSphere hosts. Their connections are strictly controlled by firewalls, as those services should not be accessible from other machines on the DMZ or directly from the Internet.
  • It is also assumed that typical datacenter security technologies, such as IDS/IPS, SIEM, configuration management, patch management, vulnerability management, anti-virus, and GRC management systems, will be applied to both the vCloud Director, its associated systems, vSphere and its associated systems, and the networks and storage infrastructure that support them.
  • Proper management of leases, quotas, limits, and allocation models can ensure that one tenant organization cannot deny service to another by accident or on purpose.
  • In these and other scenarios, resource pools, networks, and datastores should be segmented into different security domains by using different Provider VDCs whereby vApps with similar concerns can be grouped (or isolated).
  • Whenever you allow the overcommitment of resources in a pool used by more than one tenant organization, you run the risk of causing service quality to degrade for other tenants. Proper monitoring of service levels is imperative to avoid Denial of Service being caused by a "noisy neighbor" tenant, but security does not require a separation of tenants into individual resource pools to meet this goal.
  • Sometimes, an External Network may be used by an organization VDC network to connect two different vApps and their networks or to connect a vApp Network back to the enterprise datacenter. In these cases, the External Network should not be shared between tenant organizations.
  • For communications that traverse an External Network and also require confidentiality protections (for instance, a vApp-to-enterprise datacenter connection or a vApp-to-vApp bridge), it is recommended that an NSX Edge or other VPN virtual appliance be deployed in the organization VDC network.
  • If Network Pools must be shared among tenants, it is safest to share a VXLAN-backed pool, which supports many more networks than a VLAN-backed pool, and enforces isolation at the ESXi-kernel layer.
  • If you share datastores across storage profiles, you should set a storage limit, enable thin provisioning if possible, and monitor storage usage carefully. Also carefully manage vApp storage leases.
  • Virtual machines never see any storage outside of their VMDKs unless they have network connectivity to those storage systems. This guide recommends that they do not; a provider could provide access to external storage for vApps as a network service, but it must be separate from the LUNs assigned to the vSphere hosts backing the cloud.
  • As defined in vSphere Security (https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.security.doc/GUID-52188148-C579-4F6A-8335-CFBCE0DD2167.html), it is important for the management network to be separate from the virtual machine data networks.
  • Likewise, the management network must be separate from the DMZ that provides access for organization administrators.
  • The storage networks are also physically separate. This follows vSphere best practices and protects tenant organization and provider storage from malicious virtual machines.
  • vMotion is not always placed on a separate network from the management network; however, in the cloud it is important from a Separation of Duties perspective. vMotion generally takes place in the clear, and if it is put on the management network, it allows a provider administrator or other user with access to that network to "sniff" on the vMotion traffic, violating tenant privacy. For this reason, you should create a separate physical network for vMotion of cloud workloads.
  • It is part of good security practice to regularly examine logs for suspicious, unusual, or unauthorized activity. Routine log analysis will also help identify system misconfigurations and failures and help ensure adherence to SLAs.
  • A syslog server can be set up during installation. We recommend using a TLS-enabled syslog infrastructure. Exporting logs to a syslog server is recommended for multiple reasons. It is recommended that the syslog server be configured with redundancy, to ensure essential events are always logged. Security Operations and IT Operations organizations may also benefit from the centralized aggregation and management of diagnostic logs. We recommend that you use logrotate or similar methods to control the size of logs and the number of old log files to keep.
  • Ensure that you have sufficient free disk space to accommodate diagnostic logs and Jetty request logs. Centralized logging will ensure you don't lose valuable diagnostic information as the 400MB log file total is reached and files are rotated and deleted.
  • Other systems connected to and used by vCloud Director create audit logs that should be consolidated into your audit processes. These include logs from NSX, the vCloud Director database, vCenter Server, and vSphere hosts.
  • After the initial local system administrator account is created, it is strongly recommended that all system administrator accounts be managed by an Identity Provider such as LDAP or the vSphere SSO service.
  • Some cloud providers may choose to allow organizations to use an OU within the system LDAP or to host the organization's LDAP directory. In either case, appropriate management access to that directory must be provided so that users can be managed by the organization administrator. In the absence of such management controls, a tenant organization should only use a private LDAP directory that they themselves host and manage.
  • Another concern that arises when the organization is hosting their own LDAP server is exposure outside their DMZ. It is not a service that needs to be accessible to the general public, so steps should be taken to limit access only to the vCloud Director cells. One simple way to do that is to configure the LDAP server and/or the external firewall to only allow access from IP addresses that belong to the vCloud Director cells.
  • The provider can take steps to protect against this and similar intertenant attacks by both limiting the source IP addresses of requests when possible as well as ensuring that organization names it assigns to tenants are never too similar to one another.
  • vCloud Director must be configured to connect to LDAP servers over SSL in order to properly protect the passwords being validated against those servers. When configuring LDAP over SSL, do not accept all certificates.
  • Best practices for managing users and their passwords are important to understand and apply.
  • Log management, Security Information and Event Management (SIEM), or other monitoring systems, should be used to watch for attempts to crack passwords through brute force attacks.
  • It is recommended that system administrators and organization administrators passwords be safely stored in a manner approved by your IT security department.