I am considering to integrate Hashicorp Vault for “encryption at rest”. The requirement is, that each user “owns” a database and the encryption should be performed with the users key in the vault.
Is this possible at all ?
1 Like
Hello.
No, it isn’t possible. When MongoDB is applying data-at-rest encryption there is an internal table of keys, a second layer of keys you might say.
That might sound like an opportunity to have per-database keys but due to other factors it isn’t. The implementation is a single internal table of keys, and so there can only be one external key that decrypts it.
Having just a single table of other keys makes key rotation a small number of steps. But it also makes it an all-at-once process. It would take some significant reprogramming to accept multiple external keys. And errors caused by rotation of one tenant’s keys might put all tenant’s data at risk.
Another complication is that WiredTiger storage engine doesn’t discriminate between MongoDB’s database namespaces, as you see them. So more code changes in MongoDB catalog management would be required to make it intuitive to use.
I haven’t thought through the sharded cluster picture much, but no doubt there is a complication there too. Performing key rotations per node will be more time-consuming if you’re doing it for more keys, for more shards.
Sharding makes the client’s view of the collections simplified, but storage engine-based data-at-rest encryption unavoidably undermines that simplification. Only encryption and decryption applied at the mongos (a feature that doesn’t exist) or client-side encryption (a.k.a. FLE) can keep encryption with sharded clusters simple.
To give different users their own key management I recommend using separate sharded clusters or non-sharded replicasets for each.
1 Like
@Akira_Kurogane thanks for the in-depth explanation !
2 Likes
Just as a side note - lets say the databases are all encrypted with the “internal” keys and the master key gets “discovered” by the intruder - so the intruder will have access to all databases. So having different “internal” keys for each database do not make much sense. Why this detour - I guess I am missing something.
1 Like
Your point is correct - one encryption/decryption key, access to all. It’s not a security benefit to have multiple keys given points in the previous comment. I don’t know why there are myself, I just heard that there were and I can see in the code there is a table, with a get-key-by-id function for retrieving different keys.
1 Like