Re: [EXTERNAL] Re: Cassandra Encyrption between DC

[Jai Bheemsen Rao Dhanwada]

thank you

On Thu, Feb 13, 2020 at 6:30 AM Durity, Sean R 
wrote:

> I will just add-on that I usually reserve security changes as the primary
> exception where app downtime may be necessary with Cassandra. (DSE has some
> Transitional tools that are useful, though.) Sometimes a short outage is
> preferred over a longer, more-complicated attempt to keep the app up. And,
> in many cases, there is no way to guarantee availability when making
> security-related changes (new cipher suites, adding encryption, turning on
> authentication, etc.). It is better to try and have those implemented from
> the beginning, where possible.
>
>
>
>
>
> Sean Durity
>
>
>
> *From:* Erick Ramirez 
> *Sent:* Wednesday, February 12, 2020 9:02 PM
> *To:* user@cassandra.apache.org
> *Subject:* [EXTERNAL] Re: Cassandra Encyrption between DC
>
>
>
> I've just seen your questions on ASF Slack and didn't immediately make the
> connection that this post in the mailing list is one and the same. I
> understand what you're doing now -- you have an existing DC with no
> encryption and you want to add a new DC with encryption enabled but don't
> want the downtime associated with enabling encryption on the existing DC.
>
>
>
> As driftx, exlt, myself & co pointed out, there isn't a "transitional
> path" of implementing it without downtime in the current (released)
> versions of C*. Cheers!
>
> --
>
> The information in this Internet Email is confidential and may be legally
> privileged. It is intended solely for the addressee. Access to this Email
> by anyone else is unauthorized. If you are not the intended recipient, any
> disclosure, copying, distribution or any action taken or omitted to be
> taken in reliance on it, is prohibited and may be unlawful. When addressed
> to our clients any opinions or advice contained in this Email are subject
> to the terms and conditions expressed in any applicable governing The Home
> Depot terms of business or client engagement letter. The Home Depot
> disclaims all responsibility and liability for the accuracy and content of
> this attachment and for any damages or losses arising from any
> inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other
> items of a destructive nature, which may be contained in this attachment
> and shall not be liable for direct, indirect, consequential or special
> damages in connection with this e-mail message or its attachment.
>

RE: [EXTERNAL] Re: Cassandra Encyrption between DC

[Durity, Sean R]

I will just add-on that I usually reserve security changes as the primary 
exception where app downtime may be necessary with Cassandra. (DSE has some 
Transitional tools that are useful, though.) Sometimes a short outage is 
preferred over a longer, more-complicated attempt to keep the app up. And, in 
many cases, there is no way to guarantee availability when making 
security-related changes (new cipher suites, adding encryption, turning on 
authentication, etc.). It is better to try and have those implemented from the 
beginning, where possible.


Sean Durity

From: Erick Ramirez 
Sent: Wednesday, February 12, 2020 9:02 PM
To: user@cassandra.apache.org
Subject: [EXTERNAL] Re: Cassandra Encyrption between DC

I've just seen your questions on ASF Slack and didn't immediately make the 
connection that this post in the mailing list is one and the same. I understand 
what you're doing now -- you have an existing DC with no encryption and you 
want to add a new DC with encryption enabled but don't want the downtime 
associated with enabling encryption on the existing DC.

As driftx, exlt, myself & co pointed out, there isn't a "transitional path" of 
implementing it without downtime in the current (released) versions of C*. 
Cheers!



The information in this Internet Email is confidential and may be legally 
privileged. It is intended solely for the addressee. Access to this Email by 
anyone else is unauthorized. If you are not the intended recipient, any 
disclosure, copying, distribution or any action taken or omitted to be taken in 
reliance on it, is prohibited and may be unlawful. When addressed to our 
clients any opinions or advice contained in this Email are subject to the terms 
and conditions expressed in any applicable governing The Home Depot terms of 
business or client engagement letter. The Home Depot disclaims all 
responsibility and liability for the accuracy and content of this attachment 
and for any damages or losses arising from any inaccuracies, errors, viruses, 
e.g., worms, trojan horses, etc., or other items of a destructive nature, which 
may be contained in this attachment and shall not be liable for direct, 
indirect, consequential or special damages in connection with this e-mail 
message or its attachment.

Re: Cassandra Encyrption between DC

[Erick Ramirez]

I've just seen your questions on ASF Slack and didn't immediately make the
connection that this post in the mailing list is one and the same. I
understand what you're doing now -- you have an existing DC with no
encryption and you want to add a new DC with encryption enabled but don't
want the downtime associated with enabling encryption on the existing DC.

As driftx, exlt, myself & co pointed out, there isn't a "transitional path"
of implementing it without downtime in the current (released) versions of
C*. Cheers!

>

Re: Cassandra Encyrption between DC

[Erick Ramirez]

>
> ... where dc-1 have encryption enabled and dc-2 does't have encryption?

... is there a way to specify encrypt within DC?


The quick answer to your question is no. But you've got me really curious
now because you have a very strange setup which makes no sense to me and
I'm hoping you could elaborate. Effectively you're saying:
(a) you trust the network between DC1 and DC2 so you don't encrypt intra-DC
comms,
(b) but you don't trust the network in DC2 so comms between nodes in DC2
are encrypted.

That doesn't make sense to me. Is DC2 in some untrusted DMZ?

This statement also begs the question:

... where existing dc don't have encryption between the nodes but the new
> DC have encryption enabled


How do you plan to bootstrap the new nodes? And if they're already
bootstrapped, are you trying to join 2 separate clusters together? Because
if you are, that's a very bad idea. You'll end up corrupting the schema
assuming you know enough to override the cluster_name in system.local. I
would strongly advise against it if that's what you're trying to achieve.
Cheers!

Erick Ramirez  |  Developer Relations

erick.rami...@datastax.com | datastax.com 

 
 





On Thu, 13 Feb 2020 at 02:54, Jai Bheemsen Rao Dhanwada <
jaibheem...@gmail.com> wrote:

> Hello,
>
> Is there a way we can have a multi DC Cassandra cluster, where dc-1 have
> encryption enabled and dc-2 does't have encryption?
>
> I am trying to add a new DC to the existing cluster, where existing dc
> don't have encryption between the nodes but the new DC have encryption
> enabled?
>
> I see the below options, is there a way to specify encrypt within DC?
>
>- all - Encrypt all inter-node communications
>- none - No encryption
>- dc - Encrypt the traffic between the datacenters
>- rack - Encrypt the traffic between the racks
>
>