On Tue, 16 Nov 2021 at 16:17, Joseph Lynch <joe.e.ly...@gmail.com> 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 any particular opinion / I am not leaning towards any solution as of now when it comes to superiority / inferiority of file system encryption. It would be very beneficial if more people expressed their views on this matter. 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
