Allow config file to contain the keystore / truststore credentials when connecting via ssl to JMX about jmx_exporter HOT 3 OPEN

@sumitbaurai There are two usage scenarios:

Java agent

We could add the properties to the exporter YAML for use when loading the SSL configuration for HTTPS.

This could cause configuration confusion since the application's SSL properties may still require the system properties, negating the value of having the SSL configuration for HTTPS in the exporter YAML.

The Java agent is recommended.

Standalone HTTP Server

Java RMI (used by JMX) doesn't provide the necessary configuration hooks to allow non-system properties for RMI SSL configuration.

Here is a great blog on the issue: https://blogger.ziesemer.com/2010/02/jmx-avoid-java-system-properties-rmi.html

TL;DR - it requires custom code in both the Standalone HTTP server and custom code in the application (possibly implemented as a Java agent, simply to bypass using system properties.)

The standalone HTTP server is not recommended.

from jmx_exporter.

Hi Doug,

Is it not the case that the same keystore , truststore can be used for both

• Setting up ssl connection with jmx
• exposing an https url

Isn't something similar to what jmx offers possible.

  excerpt from the jmx configuration
      com.sun.management.jmxremote.ssl.config.file=filepath
      Specifies the location of the SSL configuration file. A properties
      file can be used to supply the keystore and truststore location and
      password settings thus avoiding to pass them as cleartext in the
      command-line.

      The current implementation of the out-of-the-box management agent will
      look up and use the properties specified below to configure the SSL
      keystore and truststore, if present:
          javax.net.ssl.keyStore=<keystore-location>
          javax.net.ssl.keyStorePassword=<keystore-password>
         javax.net.ssl.trustStore=<truststore-location>
         javax.net.ssl.trustStorePassword=<truststore-password>

from jmx_exporter.

@sumitbaurai not sure that will help.

Conceptually... the standalone HTTP server exporter...

1. would have to create a new/custom RMI registry with a custom SslServerSocketFactory on a non-standard port using a custom SSLContext using custom configuration to load the SSL keystore/truststore files/passwords.

2. use the custom SslServerSocketFactory in the JmxScraper code when initiating the connection to the application.

3. the application would then use the custom SslServerSocketFactory (really just the configuration since the actual class isn't serialized) to connect back to the new/custom RMI registry on the non-standard port.

4. the new/custom RMI registry would use the custom SSLContext to create the SslServerSocketFactory to accept the connection.

This all assumes that you can bind a Remote in the local RMI registry to the custom RMI registry (I have no idea if a Remote can be bound to two registries or if it can be moved.)

(I'm sure I'm missing something/left out some things.)

The complexities, code changes, integration tests, etc. to support all of this (if it would even work) for the standalone HTTP server exporter (which is not the recommended deployment scenario) simply to prevent a clear-text password doesn't feel like a worthwhile effort.

from jmx_exporter.