[ https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867136#comment-17867136 ]
Maulin Vasavada edited comment on CASSANDRA-13428 at 7/18/24 11:40 PM: ----------------------------------------------------------------------- So since there is already a `ssl_context_factory` config which allows to plug any mechanism to load the TLS credentials from, just to allow File paths for passwords would be easy by adding an implementation for `ISslContextFactory` e.g. In [FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L276] we can modify the FileBasedSslContext to add file path for the password . However, the JMX is using the [Java's SocketFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/JMXServerUtils.java#L98] which is currently reading TLS credentials from the system properties even with the Patch provided in CASSANDRA-18508. My conclusion is that- we can make two changes- # Modify existing FileBasedSslContextFactory to support file paths for the password (with additional configuration options like keystore_password_file and truststore_password_file suggested in this ticket's title) AND # Modify the JMX server utils to use SSLContext and implement JMXSslContextFactory implementation that can allow any format like existing implementations of the ISslContextFactory (like PEM based etc) without creating class-bloat (too many new classes). [~smiklosovic] [~brandon.williams] please let me know your thoughts. May be [~djoshi] 's thought also would be helpful given his/his-teams' work on this area. was (Author: maulin.vasavada): So since there is already a `ssl_context_factory` config which allows to plug any mechanism to load the TLS credentials from, just to allow File paths for passwords would be easy by adding an implementation for `ISslContextFactory` e.g. In [FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L276] we can modify the FileBasedSslContext to add file path for the password . However, the JMX is using the [Java's SocketFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/JMXServerUtils.java#L98] which is currently reading TLS credentials from the system properties even with the Patch provided in [CASSANDRA-18508|https://issues.apache.org/jira/browse/CASSANDRA-18508]. My conclusion is that- we can make two changes- # Modify existing FileBasedSslContextFactory to support file paths for the password (with additional configuration options like keystore_password_file and truststore_password_file suggested in this ticket's title) AND # Modify the JMX server utils to use SSLContext and implement JMXSSLContextFactory implementation that can allow any format like existing implementations of the ISslContextFactory (like PEM based etc) without creating class-bloat (too many new classes). [~smiklosovic] [~brandon.williams] please let me know your thoughts. May be [~djoshi] 's thought also would be helpful given his/his-teams' work on this area. > Security: provide keystore_password_file and truststore_password_file options > ----------------------------------------------------------------------------- > > Key: CASSANDRA-13428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Encryption, Local/Config > Reporter: Bas van Dijk > Assignee: Maulin Vasavada > Priority: Normal > Original Estimate: 3h > Remaining Estimate: 3h > > Currently passwords are stored in plaintext in the configuration file as in: > {code} > server_encryption_options: > keystore_password: secret > truststore_password: secret > client_encryption_options: > keystore_password: secret > {code} > This has the disadvantage that, in order to protect the secrets, the whole > configuration file needs to have restricted ownership and permissions. This > is problematic in operating systems like NixOS where configuration files are > usually stored in world-readable locations. > A secure option would be to store secrets in files (with restricted ownership > and permissions) and reference those files from the unrestricted > configuration file as in for example: > {code} > server_encryption_options: > keystore_password_file: /run/keys/keystore-password > truststore_password_file: /run/keys/truststore-password > client_encryption_options: > keystore_password_file: /run/keys/keystore-password > {code} > This is trivial to implement and provides a big gain in security. > So in summary I'm proposing to add the {{keystore_password_file}} and > {{truststore_password_file}} options besides the existing > {{keystore_password}} and {{truststore_password options}}. The former will > take precedence over the latter. -- 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