[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17723833#comment-17723833
]
Stefan Miklosovic edited comment on CASSANDRA-18508 at 5/18/23 8:00 AM:
------------------------------------------------------------------------
I too prefer cassandra.yaml.
I do not think that doing something like this is too much for a user to set up.
{code}
jmx_credentials_provider:
- class_name: org.apache.cassandra.auth.jmx.DefaultRetriever
keystore_password: "abc"
truststore_password: "def"
.....
{code}
This would be the only implementation which we would ship. So we are not
delegating it to any file. It is about the _possibility_ to place it somewhere
else. What if somebody has a Kubernetes cluster and they are fetching it from
some config map? I think having a default implementation reading it from
cassandra.yaml from that map + having ability to implement it like one pleases
is good. If we compare your idea, the only difference is one field called
"class_name".
Loading of properties into a file should be added into something like FBUtils
to have a static method reading it from a file. We may dedicate a separate
class for it if it is not just about one method only and logic would be somehow
more complex.
was (Author: smiklosovic):
I too prefer cassandra.yaml.
I do not think that doing something like this is too much for a user to set up.
{code}
jmx_credentials_provider:
- class_name: org.apache.cassandra.auth.jmx.DefaultRetriever
keystore_password: "abc"
truststore_password: "def"
.....
{code}
This would be the only implementation which we would ship. So we are not
delegating it to any file. It is about the _possibility_ to place it somewhere
else. What if somebody has a Kubernetes cluster and they are fetching it from
some config map? I think having a default implementation reading it from
cassandra.yaml from that map + having ability to implement it like one pleases
is good. If we compare your idea, the only difference is one field called
"class".
Loading of properties into a file should be added into something like FBUtils
to have a static method reading it from a file. We may dedicate a separate
class for it if it is not just about one method only and logic would be somehow
more complex.
> 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]
