On 8/4/20 10:02 AM, Jason Dillaman wrote:
On Tue, Aug 4, 2020 at 11:55 AM Joao Eduardo Luis <joao@suse.de> wrote:
On 20/08/04 09:04AM, Jason Dillaman wrote:
On Mon, Aug 3, 2020 at 4:48 PM Joao Eduardo Luis <joao@suse.de> wrote:
Even though we currently have at-rest encryption, ensuring data security on the physical device, this is currently on an OSD-basis, and it is too coarse-grained to allow different entities/clients/tenants to have their data encrypted with different keys.
The intent here is to allow different tenants to have their data encrypted at rest, independently, and without necessarily relying on full osd encryption. This way one could have anywhere between a handful to dozens or hundreds of tenants with their data encrypted on disk, while not having to maintain full at-rest encryption should the administrator consider it too cumbersome or unnecessary.
I would be interested to hear the tenant use-case where they trust the backing storage system (Ceph) with all things encryption and don't have any effective control over the keys / ciphers / rotation policies / etc. If you have a vulnerability that exposes the current OSD dm-crypt keys, I would think it would be possible to get the per-namespace keys though a similar vector if they are stored effectively side-by-side?
The idea here was not to berate the current at-rest scheme, nor propose something as better than, but a use case where it is used instead of. Maybe I'm being naive, but the trade-off of having the storage system handling the namespace keys is not much different than having it handling the dmcrypt keys.
I'm in no way saying that Ceph handling the secrets is better than having the clients doing their own encryption; it's just a different use case being addressed.
Totally understand. I am just honestly interested if this solves a known issue for Ceph users (regulatory or otherwise). i.e. would it check all the same boxes to implement pool-level encryption vs namespace-level encryption?
Indeed, pools could even be used today (one pool on dmcrypted drives, another on drives without encryption) for similar security properties.