On Fri, 19 Nov 2021 at 03:03, Joseph Lynch <joe.e.ly...@gmail.com> wrote: > > > > > 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. > > > > I agree encrypted data at rest is a very important feature, but in the six > years since the ticket was originally proposed other systems kept getting > better at a faster rate, especially easy to use full disk and filesystem > encryption. LUKS+LVM in Linux is genuinely excellent and is relatively easy > to setup today while that was _not_ true five years ago. > > > > 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. > > > > I think it's important to realize that for us to check the "data is > encrypted at rest" box we have to do a lot more than what's currently been > implemented. We have to design a pluggable key management system that > either retrieves the keys from a remote system (e.g. KMS) or gives some way > to load them directly into the process memory (virtual table? or maybe > loads them from a tmpfs mounted directory?). We can't just put the key in > the yaml file. This will also affect debuggability since we have to encrypt > every file that is ever produced by Cassandra including logs (which contain > primary keys) and heap dumps which are vital to debugging so we'll have to > ship custom tools to decrypt those things so humans can actually read them > to debug problems.
Yes, this needs to be done. The credentials for this stuff should be just fetched from wherever one wants. 100% agree with that and that maybe next iteration on top of that, should be rather easy. This was done in CEP-9 already for SSL context creation so we would just copy that approach here, more or less. I do not think you need to put the key in the yaml file. THE KEY? Why? Just a reference to it to read it from the beginning, no? What I do find quite ridiculous is to code up some tooling which would decrypt credentials in yaml. I hope we will avoid that approach here, that does not solve anything in my opinion. > If our primary goal is facilitating our users in being compliant with > encryption at rest policies, I believe it is much easier to check that box > by encrypting the entire disk or filesystem than building partial solutions > into Cassandra. > > -Joey --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
