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 authenticated
nodes, rolling restart of the servers will be a lot simpler than if the
servers were using FDE - someone will have to type in the passphrase on
each reboot, or have a script to mount the encrypted device over SSH and
then start Cassandra service after a reboot.
Another valid use case of encryption implemented in Cassandra is
selectively encrypt some tables, but leave others unencrypted. Doing
this outside Cassandra on the filesystem level is very tedious and
error-prone - a lots of symlinks and pretty hard to handle newly created
tables or keyspaces.
However, I don't know if there's enough demand to justify the above use
cases.
On 16/11/2021 14:45, Joseph Lynch wrote:
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 use an encrypted filesystem or disks instead where
the kernel or device will undoubtedly be able to do the crypto more
efficiently than we can in the JVM and we wouldn't have to further
complicate the storage engine? I think the state of encrypted
filesystems (e.g. LUKS on Linux) is significantly more user friendly
these days than it was in 2015 when that ticket was created.
If the application has existing exfiltration paths (e.g. backups) it's
probably better to encrypt/decrypt in the backup/restore process via
something extremely fast (and modern) like piping through age [1]
isn't it?
[1] https://github.com/FiloSottile/age
-Joey
On Sat, Nov 13, 2021 at 6:01 AM Stefan Miklosovic
<stefan.mikloso...@instaclustr.com> wrote:
Hi list,
an engineer from Intel - Shylaja Kokoori (who is watching this list
closely) has retrofitted the original code from CASSANDRA-9633 work in
times of 3.4 to the current trunk with my help here and there, mostly
cosmetic.
I would like to know if there is a general consensus about me going to
create a CEP for this feature or what is your perception on this. I
know we have it a little bit backwards here as we should first discuss
and then code but I am super glad that we have some POC we can
elaborate further on and CEP would just cement and summarise the
approach / other implementation aspects of this feature.
I think that having 9633 merged will fill quite a big operational gap
when it comes to security. There are a lot of enterprises who desire
this feature so much. I can not remember when I last saw a ticket with
50 watchers which was inactive for such a long time.
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
