[
https://issues.apache.org/jira/browse/CASSANDRA-10404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16191008#comment-16191008
]
Jason Brown commented on CASSANDRA-10404:
-----------------------------------------
Missed this update, for some stupid reason
bq. 1) Assuming we have a 3.x cluster already running with ssl enabled and now
start to bump the first node to 4.0. If we connect to storage_port by default
in 4.0, won't the upgraded node fail to start with a "Unable to gossip with any
seeds" error?
As I explained in the previous comment, this is the trickiest part of this
patch. The upgraded node, after it bounces, must have at least one 3.0 node
connect to it, and have a gossip session, for the upgraded node to a) learn
about the version of the node that contacted via the handshake protocol, and b)
learn about the version of other nodes in the the cluster via that round of
gossip. Having that first round of gossip is critical for getting the versions
of peers, which we check on each {{OutboundMessagingService#tryConnect}}
attempt.
This does not guarantee that the upgraded node will learn about the 3.0 status
of nodes in it's seed list before the shadow round fails, although I think the
possiblity of shadow round failure is rather low as un-upgraded nodes will be
trying to connect to the upgraded node (as it will be seen as DOWN by the
peers, and they will be attempting to connect via gossip). The possibility of
shadow round failure is non-zero, however, and I'm open to ideas on the cluster
upgrade scenario.
bq. 2) Do we want to add an option to disable the ssl_storage_port? E.g. by
setting it to the same value as storage_port?
Maybe we can add another property under the {{server_encryption_options}},
something like {{enable_legacy_ssl_storage_port}}. That would also clean up
{{MessagingService#listen}} a little bit. wdyt?
bq. 3) doc/source/operating/security.rst: needs to be updated
Yup, I'll be happy do so when we have solid idea of where the code is going.
bq. 4) cassandra.yaml: comments for storage_port and ssl_storage_port not
accurate anymore, as both can use encryption now. We also should clearly
describe the port as legacy port only used during upgrades. There should be a
link to security.rst for further details.
Ahh, good catch. Let's figure out the code and yaml props first, then I'll come
back to properly wording the yaml comments.
bq. 5) Some of the native transport and internode netty code has become
redundant, e.g. Server.OptionalSecureInitializer and the new
OptionalSslHandler. It's probably not in scope of this ticket, but should maybe
addressed in another ticket at some point.
I totally agree about the redundancy, and I would like to make that a follow up
ticket.
bq. 6) Use of server_encryption in NettyFactory.OutboundInitializer could use
some comments, especially on why we don't have to check all remaining options
such as internode_encryption (already checked in MessagingService)
I've added a comment to {{NettyFactory.OutboundInitializeer#initChannel()}}
about where the TLS determination happens, but admittedly I'm not a fan of
burying the pointer to that so far down the code path. Not sure what's a better
solution ...
> Node to Node encryption transitional mode
> -----------------------------------------
>
> Key: CASSANDRA-10404
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10404
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Tom Lewis
> Assignee: Jason Brown
> Fix For: 4.x
>
>
> Create a transitional mode for encryption that allows encrypted and
> unencrypted traffic node-to-node during a change over to encryption from
> unencrypted. This alleviates downtime during the switch.
> This is similar to CASSANDRA-10559 which is intended for client-to-node
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
