You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Current »

Status

Current state: Adopted

Discussion thread: here

Vote thread: here

JIRA: KAFKA-7455

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Currently both password authentication and SSL are disabled by default (namely all security are disabled) when monitoring remotely. If we enable either of them when starting the Java VM, the current JmxTool will no longer work and result in a "java.rmi.ConnectIOException". The problem is that JmxTool does not specify SslRMIClientSocketFactory or JMXConnector.CREDENTIALS when it tries to connect a security-enabled JMX RMI port.

In order to add capability to connect to a secured RMI port, we can leverage JmxTool to add two options "--jmx-ssl-enable" and "--jmx-auth-prop" to pass an environment map that contains relevant certification entry.

Public Interfaces

This change would add two additional options "--jmx-ssl-enable" and "--jmx-auth-prop" to JmxTool:

val jmxAuthPropOpt = parser.accepts("jmx-auth-prop", "A mechanism to pass property in the form 'username=password' " +
  "when enabling remote JMX with password authentication.")
  .withRequiredArg
  .describedAs("jmx-auth-prop")
  .ofType(classOf[String])
val jmxSslEnableOpt = parser.accepts("jmx-ssl-enable", "Flag to enable remote JMX with SSL.")
  .withRequiredArg
  .describedAs("ssl-enable")
  .ofType(classOf[java.lang.Boolean])
  .defaultsTo(false)

Proposed Changes

The change proposed in this KIP is to add two extra options as stated above and to connect to a secured RMI port when enable either SSL or Password Authentication. This would be a backward compatible change leaving the previous options available.

Specific behavior changes

  • Providing --jmx-ssl-enable when enable SSL
  • Providing --jmx-auth-prop when enable Password Authentication
  • Providing both options above when enable all security

Compatibility, Deprecation, and Migration Plan

The proposed change has no impact on existing code and is backwards compatible. 

Rejected Alternatives

None so far.

  • No labels