cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Brown (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-10404) Node to Node encryption transitional mode
Date Sat, 15 Apr 2017 00:45:41 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-10404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15969734#comment-15969734
] 

Jason Brown edited comment on CASSANDRA-10404 at 4/15/17 12:45 AM:
-------------------------------------------------------------------

Linked is a first pass at implementing this behavior, based on the current (in-flight) CASSANDRA-8457.
I'm posting this now to get some feedback on the idea/implementation. Hence, I haven't added
tests (or dtests) yet. As [~spodxx@gmail.com] noted, adding in this functionality is rather
trivial with CASSANDRA-8457 in place. 

The essence of this patch is to add two new configuration props to the {{ServerEncryptionOptions}},
{{optional}} and {{enabled}}. They will be functional equivalent to what we already have for
{{ClientEncryptionOptions}}, and thus allow us to do unencrypted and encrypted communication
from the same listening internode messaging socket. Most of the patch is refactoring of the
{{EncryptionOptions}} and {{OptionalSslHandler}} classes, and the interesting functional bits
are in the yaml and MessagingService.

bq. But how would we handle such transition when it comes to used storage_ports?

I'm imagining that for 4.0 we still need both {{storage_port}} and {{ssl_storage_port}} in
place to support cluster upgrades. Upgraded nodes will be smart enough to connect on the {{storage_port}}
(which will be intelligent to figure out if the connection is TLS or not). Unupgraded nodes
can still connect on the legacy port (as we'll need to listen on it, as well). At 5.0, then,
we can retire the {{ssl_storage_port}} and simply have one port and config option for internode
messaging with TLS.

Also, once this ticket is in place, it will make [~aweisberg]'s patch for CASSANDRA-7544 simpler
as he won't (hopefully!) need to worry about passing around the {{ssl_storge_port}} as all
4.0 nodes who can listen to the new CASSANDRA-7544 data being passed around will also be smart
enough to connect to the {{storage_port}} for TLS behavior. Hence, another reason I'm eager
to get this in.


was (Author: jasobrown):
Linked is a first pass at implementing this behavior, based on the current (in-flight) CASSANDRA-8457.
I'm posting this now to get some feedback on the idea/implementation. Hence, I haven't added
tests (or dtests) yet. As [~spodxx@gmail.com] noted, adding in this functionality is rather
trivial with CASSADNRA-8457 in place. 

The essence of this patch is to add two new configuration props to the {{ServerEncryptionOptions}},
{{optional}} and {{enabled}}. They will be functional equivalent to what we already have for
{{ClientEncryptionOptions}}, and thus allow us to do unencrypted and encrypted communication
from the same listening internode messaging socket. Most of the patch is refactoring of the
{{EncryptionOptions}} and {{OptionalSslHandler}} classes, and the interesting functional bits
are in the yaml and MessagingService.

bq. But how would we handle such transition when it comes to used storage_ports?

I'm imagining that for 4.0 we still need both {{storage_port}} and {{ssl_storage_port}} in
place to support cluster upgrades. Upgraded nodes will be smart enough to connect on the {{storage_port}}
(which will be intelligent to figure out if the connection is TLS or not). Unupgraded nodes
can still connect on the legacy port (as we'll need to listen on it, as well). At 5.0, then,
we can retire the {{ssl_storage_port}} and simply have one port and config option for internode
messaging with TLS.

Also, once this ticket is in place, it will make [~aweisberg]'s patch for CASSANDRA-7544 simpler
as he won't (hopefully!) need to worry about passing around the {{ssl_storge_port}} as all
4.0 nodes who can listen to the new CASSANDRA-7544 data being passed around will also be smart
enough to connect to the {{storage_port}} for TLS behavior. Hence, another reason I'm eager
to get this in.

> 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
>
> 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.3.15#6346)

Mime
View raw message