You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Joseph Lynch (JIRA)" <ji...@apache.org> on 2019/05/30 18:40:00 UTC
[jira] [Created] (CASSANDRA-15146) Transitional TLS configuration
options are overly complex
Joseph Lynch created CASSANDRA-15146:
----------------------------------------
Summary: Transitional TLS configuration options are overly complex
Key: CASSANDRA-15146
URL: https://issues.apache.org/jira/browse/CASSANDRA-15146
Project: Cassandra
Issue Type: Bug
Reporter: Joseph Lynch
Assignee: Joseph Lynch
It appears as part of the port from transitional client TLS to transitional server TLS in CASSANDRA-10404 (the ability to switch a cluster to using {{internode_encryption}} without listening on two ports and without downtime) we carried the {{enabled}} setting over from the client implementation. I believe that the {{enabled}} option is redundant to {{internode_encryption}} and {{optional}} and it should therefore be removed prior to the 4.0 release where we will have to start respecting that interface.
Current trunk yaml:
{noformat}
server_encryption_options:
# set to true for allowing secure incoming connections
enabled: false
# If enabled and optional are both set to true, encrypted and unencrypted connections are handled on the storage_port
optional: false
# if enabled, will open up an encrypted listening socket on ssl_storage_port. Should be used
# during upgrade to 4.0; otherwise, set to false.
enable_legacy_ssl_storage_port: false
# on outbound connections, determine which type of peers to securely connect to. 'enabled' must be set to true.
internode_encryption: none
keystore: conf/.keystore
keystore_password: cassandra
truststore: conf/.truststore
truststore_password: cassandra
{noformat}
I propose we eliminate {{enabled}} and just use {{optional}} and {{internode_encryption}} to determine the listener setup. I also propose we change the default of {{optional}} to true. We could also re-name {{optional}} since it's a new option but I think it's good to stay consistent with the client and use {{optional}}.
||optional||internode_encryption||description||
|true|none|(default) No encryption is used but if a server reaches out with it we'll use it|
|false|dc|Encryption is required for inter-dc communication, but not intra-dc|
|false|all|Encryption is required for all communication|
|false|none|We listen for either encrypted or unencrypted|
|true|dc|Encryption is used for inter-dc communication but is not required|
|true|all|Encryption is used for all communication but is not required|
From these states it is clear when we should be accepting TLS connecitons (all except for the first) as well as when we must enforce it.
To transition without downtime from an un-encrypted cluster to an encrypted cluster the user would do the following:
1. After adding valid truststores, change {{internode_encryption}} to the desired level of encryption (recommended {{all}}) and restart Cassandra
2. Change {{optional=false}} and restart Cassandra
If {{optional}} defaulted to {{false}} as it does right now we'd need a third restart to first change {{optional}} to {{true}}, which given my understanding of the OptionalSslHandler isn't really relevant.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org