[
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:47 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.
The current internal class hierarchy can be found on the Cassandra's [Security
documentation|https://cassandra.apache.org/doc/stable/cassandra/operating/security.html#tlsssl-encryption].
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).
## And add `jmx_encryption_options` configuration in the cassandra yaml as
discussed on the other ticket's thread. This configuration will default to use
DefaultJMXSslContextFactory implementation that exactly supports defaults of
client/server encryption options configuration.
[~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.
I will try to put this thing together as code to have better clarity (and help
me self-realize if there are any challenges doing it this way :) )
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.
The current internal class hierarchy can be found on the Cassandra's [Security
documentation|https://cassandra.apache.org/doc/stable/cassandra/operating/security.html#tlsssl-encryption].
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).
## And add `jmx_encryption_options` configuration in the cassandra yaml as
discussed on the other ticket's thread. This configuration will default to use
DefaultJMXSslContextFactory implementation that exactly supports defaults of
client/server encryption options configuration.
[~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: [email protected]
For additional commands, e-mail: [email protected]
