+1
On Tue, Nov 16, 2021 at 10:14 AM Andrés de la Peña
wrote:
> +1
>
> On Tue, 16 Nov 2021 at 08:39, Sam Tunnicliffe wrote:
>
> > +1
> >
> > > On 15 Nov 2021, at 19:42, Branimir Lambov wrote:
> > >
> > > Hi everyone,
> > >
> > > I would like to start a vote on this CEP.
> > >
> > > Proposal:
>
For FDE you'd probably have the key file in a tmpfs pulled from a
remote secret manager and when the machine boots it mounts the
encrypted partition that contains your data files. I'm not aware of
anyone doing FDE with a password in production. If you wanted
selective encryption it would make sens
I don't like the idea that FDE Full Disk Encryption as an alternative to
application managed encryption at rest. Each has their own advantages
and disadvantages.
For example, if the encryption key is the same across nodes in the same
cluster, and Cassandra can share the key securely between au
On Tue, 16 Nov 2021 at 16:17, Joseph Lynch wrote:
>
> > I find it rather strange to offer commit log and hints
> encryption at rest but for some reason sstable encryption would be
> omitted.
>
> I also think file/disk encryption may be superior in those cases
Just for the record, I do not have an
> I find it rather strange to offer commit log and hints
encryption at rest but for some reason sstable encryption would be
omitted.
I also think file/disk encryption may be superior in those cases, but
I imagine they were easier to implement in that you don't have to
worry nearly as much about ke
+1
On Tue, 16 Nov 2021 at 08:39, Sam Tunnicliffe wrote:
> +1
>
> > On 15 Nov 2021, at 19:42, Branimir Lambov wrote:
> >
> > Hi everyone,
> >
> > I would like to start a vote on this CEP.
> >
> > Proposal:
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-17%3A+SSTable+format+API
>
I don't object to having the discussion about whether we actually need
this feature at all :)
Let's hear from people in the field what their perception is on this.
Btw, if we should rely on file system encryption, for what reason is
there encryption of commit logs and hints already? So this shoul
I think a CEP is wise (or a more thorough design document on the
ticket) given how easy it is to do security incorrectly and key
management, rotation and key derivation are not particularly
straightforward.
I am curious what advantage Cassandra implementing encryption has over
asking the user to u
Then you are reusing the same KEK for all SSTable files belong to the
same Cassandra table.
The reason to have KEK derived from some unique information is to avoid
reusing keys which may open up some attack vectors.
On that thought, table UUID+GEN is actually not good enough, because the
tab
Ok, but this does not need to be something which is _explicitly_ sent
to it as I believe a receiving node can derive this on its own - if we
way that gen is a hash of keyspace + table + table id, for example
(which is same across the cluster for each node).
On Tue, 16 Nov 2021 at 13:55, Bowen Song
If the same user chosen key Km is used across all nodes in the same
cluster, the sender will only need to share their SSTable generation GEN
with the receiving side. This is because the receiving side will need to
use the GEN to reproduce the KEK used in the source node. The receiving
side will
I’m not suggesting enforcing network encryption, just prohibiting
unauthenticated connections from peers so that we do not effectively offer a
decrypt-all-the-data endpoint.
If as an operator you know that it is impossible for unauthenticated peers to
open a connection due to your network confi
I think a warning message is fine, but Cassandra should not enforce
network encryption when on-disk encryption is enabled. It's definitely a
valid use case to have Cassandra over IPSec without enabling TLS.
On 16/11/2021 12:02, bened...@apache.org wrote:
We already have the facility to authent
Thanks for the insights of everybody.
I would like to return to Km. If we require that all Km's are the same
before streaming, is it not true that we do not need to move any
secrets around at all? So TLS would not be required either as only
encrypted tables would ever be streamed. That way Kr woul
We already have the facility to authenticate peers, I am suggesting we should
e.g. refuse to enable encryption if there is no such facility configured for a
replica, or fail to start if there is encrypted data present and no
authentication facility configured.
It is in my opinion much more prob
I think authenticating a receiving node is important, but it is perhaps
not in the scope of this ticket (or CEP if it becomes one). This applies
to not only encrypted SSTables, but also unencrypted SSTables. A
malicious node can join the cluster and send bogus requests to other
nodes is a gener
No, the Km does not need to be the same across nodes. Each node can
store their own encryption info file created by their own Km. The
streaming process only requires the Kr is shared.
A quick description of the streaming process via an insecure connection:
1. the sender unwrap the wrapped key
I assume the key would be decrypted before being streamed, or perhaps encrypted
using a public key provided to you by the receiving node. This would permit
efficient “zero copy” streaming for the data portion, but not require any
knowledge of the recipient node’s master key(s).
Either way, we w
Ok but this also means that Km would need to be the same for all nodes right?
If we are rolling in node by node fashion, Km is changed at node 1, we
change the wrapped key which is stored on disk and we stream this
table to the other node which is still on the old Km. Would this work?
I think we w
Yes, that's correct. The actual key used to encrypt the SSTable will
stay the same once the SSTable is created. This is a widely used
practice in many encrypt-at-rest applications. One good example is the
LUKS full disk encryption, which also supports multiple keys to unlock
(decrypt) the same
I really believe we likely need a CEP for this. This gets complicated
pretty fast with all the details attached and I do not want to have
endless discussions about this in the ticket.
I can clearly see this is something a broader audience needs to vote
on eventually.
On Tue, 16 Nov 2021 at 09:56,
Hi Bowen, Very interesting idea indeed. So if I got it right, the very
key for the actual sstable encryption would be always the same, it is
just what is wrapped would differ. So if we rotate, we basically only
change Km hence KEK hence the result of wrapping but there would still
be the original K
+1
> On 15 Nov 2021, at 19:42, Branimir Lambov wrote:
>
> Hi everyone,
>
> I would like to start a vote on this CEP.
>
> Proposal:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-17%3A+SSTable+format+API
>
> Discussion:
> https://lists.apache.org/thread.html/r636bebcab4e678dbee042
+1
On 16/11/21 2:27, Nate McCall wrote:
> +1
>
>
> On Tue, Nov 16, 2021 at 8:43 AM Branimir Lambov wrote:
>
>> Hi everyone,
>>
>> I would like to start a vote on this CEP.
>>
>> Proposal:
>>
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-17%3A+SSTable+format+API
>>
>> Discussion:
>>
24 matches
Mail list logo
