> 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 key management since both commit logs and hints are short lived files that should never leave the box (except maybe for CDC but I feel like that's similar to backup in terms of "exfiltration by design"). To be clear, I think in 2015 this feature would have been extremely useful, but with operating systems and cloud providers often offering full disk encryption by default now and doing it with really good (performant and secure) implementations ... I question if it's something we want to sink cycles into. -Joey On Tue, Nov 16, 2021 at 7:01 AM Stefan Miklosovic <stefan.mikloso...@instaclustr.com> wrote: > > 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 should be > removed? I find it rather strange to offer commit log and hints > encryption at rest but for some reason sstable encryption would be > omitted. > > On Tue, 16 Nov 2021 at 15:46, Joseph Lynch <joe.e.ly...@gmail.com> 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
