I believe that remote JMX access should NOT be enabled by default in any Ignite distributions - neither docker nor regular binary package.
Enabling remote JMX requires caution. It is a powerful interface, and the fact that ignite.sh enables it by default with no security (!) bothers me a lot. One could play the "THIS IS A SECURITY BUG!!!" card here, and this wouldn't be too far from truth. I have also seen issues when a user who tried to enable remote JMX manually, following all best practices and enabling security, ran into issues due to ignite.sh overriding the user-provided JMX options. Overall, I'd say that a user who doesn't know if they need remote JMX should start without it. A user who knows they need remote JMX should configure it with the necessary security options, and the best way to do that in Ignite is currently to run with -nojmx (disabling ignite.sh's default options) and providing your own options. In other words, JMX options coming from ignite.sh do no good. Note that this is all about remote JMX only. Local JMX monitoring (e.g. using JConsole or Prometheus Java agent exporter) is always available, even without any Java options. I suggest to go ahead and disable remote JMX by default in Docker in 2.9, and plan to remove the remote JMX properties setting from ignite.sh in 2.10. Thanks, Stan > On 22 Sep 2020, at 18:41, Aleksandr Shapkin <[email protected]> wrote: > > Hi all, > > There is the run.sh script that’s required for docker images deployment and > internally it just invokes the default ignite.sh script prior to starting a > node. > > So far, so good, but we discovered that it doesn’t propagate system signals > to the JVM due to its internal logic and also lacks some configuration > parameters, like JVM options, therefore we have rewritten it in > https://issues.apache.org/jira/browse/IGNITE-13453 > <https://issues.apache.org/jira/browse/IGNITE-13453> and hope to include it > in 2.9 release. > > As it turned out there was another reason for modifying the script – there > was no way of disabling JMX using it, i.e. to set -nojmx=1, the flag > supported by ignite.sh. With the new version, JMX is disabled by default and > should be turned on explicitly setting the JVM options, like > -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=49112, > Dcom.sun.management.jmxremote.authenticate=false > -Dcom.sun.management.jmxremote.ssl=false > > As far as I can remember, there were some drawbacks with the default JMX > setting and ignite.sh – It reduces security and could conflict with the > control.sh, since it’s trying to open the same port. But it’s the subject for > a separate discussion. > > So the question is – do we need to set those properties by default (enable > JMX), most likely copying them from ignite.sh or it’s fine to have JMX > disabled by default for k8s/docker deployment? > > -- > Alex.
