[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17723091#comment-17723091
]
Stefan Miklosovic edited comment on CASSANDRA-18508 at 5/16/23 11:12 AM:
-------------------------------------------------------------------------
When I firstly stumbled upon this ticket I was thinking - "wait ... are not
there these credentials in cassandra.yaml already"? But then I realized these
ones are for CQL connections and not for JMX. Neverthless I feel like if we
have yet another source of properties, it is starting to be a little bit too
much. cassandra.yaml, then cassandra-env.sh which tries to externalize them to
yet another file. Putting it all to cassandra.yaml does make indeed sense.
One advantage of doing it via cassandra.yaml is that we might do this pluggable
by means of ParameterisedClass. E.g. seed_provider is based on that. So, out of
the box, we would have a retriever of these credentials from a file, then
somebody can code whatever source they want and just put it to class path.
{code}
jmx_credentials_provider:
- class_name: org.apache.cassandra.auth.jmx.DefaultFileRetriever
file: /path/to/jmx/credentials.properties
{code}
or we could do it like this:
{code}
jmx_credentials_provider:
- class_name: org.apache.cassandra.auth.jmx.DefaultFileRetriever
keystore_password: "abc"
truststore_password: "def"
.....
{code}
Then DefaultFileRetriever would parse what is in "file".
If this makes security better I do not see any big problem why we could not
provide a patch for 4.0 as well. I think that security patches should go in
regardless of the versions but that is just my humble opinion.
However, we still have to make the old way of reading these properties
available. We may deprecate it in 5.0 in favor of this cassandra.yml mechanism
described above and we would eventually remove retrieval of these properties
from other sources but file in 6.0.
was (Author: smiklosovic):
When I firstly stumbled upon this ticket I was thinking - "wait ... are not
there these credentials in cassandra.yaml already"? But then I realized these
ones are for CQL connections and not for JMX. Neverthless I feel like if we
have yet another source of properties, it is starting to be a little bit too
much. cassandra.yaml, then cassandra-env.sh which tries to externalize them to
yet another file. Putting it all to cassandra.yaml does make indeed sense.
One advantage of doing it via cassandra.yaml is that we might do this pluggable
by means of ParameterisedClass. E.g. seed_provider is based on that. So, out of
the box, we would have a retriever of these credentials from a file, then
somebody can code whatever source they want and just put it to class path.
{code}
jmx_credentials_provider:
- class_name: org.apache.cassandra.auth.jmx.DefaultFileRetriever
file: /path/to/jmx/credentials.properties
{code}
Then DefaultFileRetriever would parse what is in "file".
If this makes security better I do not see any big problem why we could not
provide a patch for 4.0 as well. I think that security patches should go in
regardless of the versions but that is just my humble opinion.
However, we still have to make the old way of reading these properties
available. We may deprecate it in 5.0 in favor of this cassandra.yml mechanism
described above and we would eventually remove retrieval of these properties
from other sources but file in 6.0.
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
