I wanted to provide a bit of background in the interest we've seen in this ticket/feature (at Instaclustr) - essentially it comes down to in-db encryption at rest being a feature that compliance people are used to seeing in databases and having a very hard time believing that operating system level encryption is an equivalent control (whatever the reality may be). I've seen this be a significant obstacle for people who want to adopt Apache Cassandra many times and an insurmountable obstacle on multiple occasions. From what I've seen, I think this is one of the most watched tickets with the most "is this coming soon" comments in the project backlog and it's something we pretty regularly get asked whether we know if/when it's coming.
That said, I completely agree that we don't want to be engaging in security theatre or " introducing something that is either insecure or too slow to be useful." and I think there are some really good suggestions in this thread to come up with a strong solution for what will undoubtedly be a pretty complex and major change. Cheers Ben On Wed, 17 Nov 2021 at 03:34, Joseph Lynch <joe.e.ly...@gmail.com> wrote: > 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 sense to me to support placing > keyspaces on different data directories (this may already be possible) > but since crypto in the kernel is so cheap I don't know why you'd do > selective encryption. Also I think it's worth noting many hosting > providers (e.g. AWS) just encrypt the disks for you so you can check > the "data is encrypted at rest" box. > > I think Cassandra will be pretty handicapped by being in the JVM which > generally has very slow crypto. I'm slightly concerned that we're > already slow at streaming and compaction, and adding slow JVM crypto > will make C* even less competitive. For example, if we have to disable > full sstable streaming (zero copy or otherwise) I think that would be > very unfortunate (although Bowen's approach of sharing one secret > across the cluster and then having files use a key derivation function > may avoid that). Maybe if we did something like CASSANDRA-15294 [1] to > try to offload to native crypto like how internode networking did with > tcnative to fix the perf issues with netty TLS with JVM crypto I'd > feel a little less concerned but ... crypto that is both secure and > performant in the JVM is a hard problem ... > > I guess I'm just concerned we're going to introduce something that is > either insecure or too slow to be useful. > > -Joey > > On Tue, Nov 16, 2021 at 8:10 AM Bowen Song <bo...@bso.ng.invalid> wrote: > > > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
