As described in the vCloud Director Administrator's Guide, each vCloud Director cell exposes a number of MBeans through JMX to allow for operational management of the server and to provide access to internal statistics. Because this interface can expose sensitive information about the running system and impact its operation, it is imperative that access to JMX be strictly controlled.

JMX Authentication

The JMX interface is accessible only to vCloud Director system administrators, who must authenticate to JMX using the same credentials they use to access vCloud Director. This feature is not configurable.

Limiting Connections to JMX

Since JMX is a management interface meant only for system administrators, there is no reason for it to be exposed outside the vCloud Director's management network. If the system 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 address specified during system configuration. You can override this default 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 most secure configuration binds the JMX connector to the localhost address:
vcloud.cell.ip.management=127.0.0.1

Regardless of the routing and firewalling devices employed, the IP addresses assigned to this management network and the JMX port (default=8999) should not be allowed to traverse the network boundary to the Internet or organization users.

With this setting in global.properties, JMX can be reached only from the local vCloud Director system. No external connections to the JMX port will succeed regardless of the routing configuration of the network.

Securing JMX Communications

If JMX is exposed only to the localhost address (127.0.0.1), then you can secure JMX communications through the use of SSH as a tunneling mechanism for any access to JMX.

If your management requirements do not allow the use of this configuration and JMX must be exposed outside the vCloud Director cell, then JMX should be secured with HTTPS, which you can configure by setting the following environment variable:
# export VCLOUD_JAVA_OPTS="-Dcom.sun.management.jmxremote.ssl=true \
-Djavax.net.keyStore=pathTokeystore \
-Djavax.net.sll.keyStorePassword=password \
-Djavax.net.ssl.keyStoreType=storeType"

You must then restart vCloud Director.

JMX clients must now connect with HTTPS, but they must have access to the CA certificate. For example, for jconsole you should import the CA certificate to a keystore on the machine that will run jconsole. Then start jconsole with the following command-line arguments:
# jconsole -J-Djavax.net.ssl.trustStoreType=store type \
-J-Djavax.net.ssl.trustStore=pathTokeystore \
-J-Djavax.net.ssl.trustStorePassword=password 
		

Self-signed certificates (not recommended for a production deployment) would make this process unwieldy, as you'd need each self-signed certificate in a keystore on the machine running the JMX client. CA-signed certificates are easier to support here as only the CA certificate is required at the JMX client machine.