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.
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
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.
# 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.
# 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.