[jira] [Comment Edited] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867181#comment-17867181
]
Maulin Vasavada edited comment on CASSANDRA-13428 at 7/19/24 6:12 AM:
--
After re-looking at the patch for
[CASSANDRA-18508|https://github.com/apache/cassandra/pull/2338/files#diff-9582994c492faf525011dc9af77fb3c06f48d78d4e04666538a36bb019af8f1d]
and my above thinking, I am exactly sure what needs to be done. What I
mentioned above should work.
was (Author: maulin.vasavada):
After re-looking at the patch for CASSANDRA-18508 and my above thinking, I am
exactly sure what needs to be done. What I mentioned above should work.
> 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
[jira] [Comment Edited] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
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}
>
[jira] [Comment Edited] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
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:46 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.
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.
[~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
[jira] [Comment Edited] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
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:45 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.
[~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.
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).
[~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 unr
[jira] [Comment Edited] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
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:42 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).
[~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.
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-pa
[jira] [Comment Edited] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
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 {{ke
[jira] [Comment Edited] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17862600#comment-17862600
]
Maulin Vasavada edited comment on CASSANDRA-13428 at 7/2/24 9:31 PM:
-
Can this be addressed with a similar approach mentioned in
https://issues.apache.org/jira/browse/CASSANDRA-18508 ? I think having a
pluggable credentials provider (parameterized class) make sense to provide a
unified solution to multiple passwords/credentials we have today in config
files. This will help in either fetching the credentials from a file, env
variables (e.g. K8s env vars) etc vs just files.
However by 'unified' I don't mean a 'single class'. Just a single interface and
a mechanism and have ability to write providers if needed. We must also provide
implementation to address the tickets in the concern as well.
was (Author: maulin.vasavada):
Can this be addressed with a similar approach mentioned in
https://issues.apache.org/jira/browse/CASSANDRA-18508 ? I think having a
pluggable credentials provider (parameterized class) make sense to provide a
unified solution to multiple passwords/credentials we have today in config
files. This will help in either fetching the credentials from a file, env
variables (e.g. K8s env vars) etc vs just files.
However by 'unified' I don't mean a 'single class'. Just a single interface and
a mechanism and have ability to write providers if needed.
> 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: Local/Config
>Reporter: Bas van Dijk
>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
[jira] [Comment Edited] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17862600#comment-17862600
]
Maulin Vasavada edited comment on CASSANDRA-13428 at 7/2/24 9:30 PM:
-
Can this be addressed with a similar approach mentioned in
https://issues.apache.org/jira/browse/CASSANDRA-18508 ? I think having a
pluggable credentials provider (parameterized class) make sense to provide a
unified solution to multiple passwords/credentials we have today in config
files. This will help in either fetching the credentials from a file, env
variables (e.g. K8s env vars) etc vs just files.
However by 'unified' I don't mean a 'single class'. Just a single interface and
a mechanism and have ability to write providers if needed.
was (Author: maulin.vasavada):
Can this be addressed with a similar approach mentioned in
https://issues.apache.org/jira/browse/CASSANDRA-18508 ? I think having a
pluggable credentials provider (parameterized class) make sense to provide a
unified solution to multiple passwords/credentials we have today in config
files. This will help in either fetching the credentials from a file, env
variables (e.g. K8s env vars) etc vs just files.
> 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: Local/Config
>Reporter: Bas van Dijk
>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
[jira] [Comment Edited] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17862601#comment-17862601
]
Maulin Vasavada edited comment on CASSANDRA-13428 at 7/2/24 9:27 PM:
-
It has been a while since I touched this code :( (bumps ahead :) ) but I can
try to work out a solution in next few weeks/months.
was (Author: maulin.vasavada):
It has been a while I touched this code :( (bumps ahead :) ) but I can try to
work out a solution in next few weeks/months.
> 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: Local/Config
>Reporter: Bas van Dijk
>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
