[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17723781#comment-17723781
]
Anthony Grasso edited comment on CASSANDRA-18508 at 5/18/23 4:00 AM:
---------------------------------------------------------------------
I really like the idea of having the alternative location for the JMX
properties defined in the _cassandra.yaml_. While I think having pluggable is a
neat idea, I think we should just add the ability to optionally specify the JMX
encryption settings in only the _cassandra.yaml_ file.
Having a pluggable setting in this case adds more complexity to configure the
encryption settings which are already difficult enough to configure.
Introducing the pluggable file loader adds a layer of indirection and has the
same drawback as my original proposal.
I propose we have a new set of encryption settings in the _cassandra.yaml_ file
that either uses or extends the existing {{EncryptionOptions}} class.
{code:java}
jmx_encryption_options:
enabled: <boolean>
keystore: <string>
keystore_password: <string>
keystore_type: <string>
truststore: <string>
truststore_password: <string>
truststore_type: <string>
require_client_auth: <boolean>
protocols: [<string>]
cipher_suites: [<string>]
{code}
An other thing to consider is [~toblin] made a good suggestion in a [comment on
the pull
request|https://github.com/apache/cassandra/pull/2338#pullrequestreview-1427792356]
to have one single way to load system properties into the JVM from a file into
Cassandra in general. I feel this idea is mutually exclusive to the idea of
placing the JMX encryption options in to the _cassandra.yaml_.
I think we should implement the functionality to optionally allow the JMX
encryption options to be placed in the _cassandra.yaml_ and create a ticket for
method to load the system properties into the JVM from a file (which I'd be
happy to implement as well). Whilst loading the JVM properties from a file
solves the issue, I feel it is broader in scope than what this ticket is trying
to solve.
was (Author: anthony):
I really like the idea of having the alternative location for the JMX
properties defined in the _cassandra.yaml_. I think we should just add the
ability to optionally specify the JMX encryption settings in only the
_cassandra.yaml_ file.
I think having a pluggable setting in this case adds more complexity to
configure the encryption settings which are already difficult enough to
configure. If we had a {{org.apache.cassandra.auth.jmx.DefaultFileRetriever}},
it would mean that a property in _canssandra-env.sh_ file would need to point
to the _cassandra.yaml file_. Then a setting in the _cassandra.yaml_ file would
need to point to a properties file. I feel it is too many layers of indirection
which may make debugging difficult.
I propose we have a new set of encryption settings in the _cassandra.yaml_ file
that either uses or extends the existing {{EncryptionOptions}} class.
{code:java}
jmx_encryption_options:
enabled: <boolean>
keystore: <string>
keystore_password: <string>
keystore_type: <string>
truststore: <string>
truststore_password: <string>
truststore_type: <string>
require_client_auth: <boolean>
protocols: [<string>]
cipher_suites: [<string>]
{code}
An other thing to consider is [~toblin] made a good suggestion in a [comment on
the pull
request|https://github.com/apache/cassandra/pull/2338#pullrequestreview-1427792356]
to have one single way to load system properties into the JVM from a file into
Cassandra in general. I feel this idea is mutually exclusive to the idea of
placing the JMX encryption options in to the _cassandra.yaml_.
I think we should implement the functionality to optionally allow the JMX
encryption options to be placed in the _cassandra.yaml_ and create a ticket for
method to load the system properties into the JVM from a file (which I'd be
happy to implement as well). Whilst loading the JVM properties from a file
solves the issue, I feel it is broader in scope than what this ticket is trying
to solve.
> Sensitive JMX SSL configuration options can be easily exposed
> -------------------------------------------------------------
>
> Key: CASSANDRA-18508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18508
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
> Reporter: Anthony Grasso
> Assignee: Anthony Grasso
> Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
>
> We need a way to specify sensitive JMX SSL configuration options to avoid
> them being easily exposed.
> When encrypting the JMX connection the passwords for the key and trust stores
> must be specified using the {{javax.net.ssl.keyStorePassword}} and
> {{javax.net.ssl.trustStorePassword}} options respectively in the
> _cassandra-env.sh_ file. After Cassandra is started it is possible to see the
> passwords by looking the running process ({{ps aux | grep "cassandra"}}).
> Java 8 has the ability to specify a configuration file that can contain these
> security sensitive settings using the {{com.sun.management.config.file}}
> argument. However, despite what the documentation
> ([https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html#gdevf])
> says, both the {{com.sun.management.jmxremote}} and
> {{com.sun.management.jmxremote.port}} arguments need to be defined in the
> _cassandra-env.sh_ for the JVM to read the contents of the file.
> The problem with defining the {{com.sun.management.jmxremote.port}} argument
> is it conflicts with the {{cassandra.jmx.remote.port}} argument. Even if the
> port numbers are different, attempting an encrypted JMX connection using
> {{nodetool}} fails and we see a {{ConnectException: 'Connection refused
> (Connection refused)'}} error.
> One possible way to fix this is to introduce a new option that would allow a
> file to be passed containing the JMX encryption options.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
