> > 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. 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