On 2020-08-06T18:55:29, Jan Fajerski <jfajerski@suse.com> wrote: Hi all, let me try to add a few comments on the use case.
Just to expand on Joao's points a little. Afaiu the use case can be considered as a quick and safe data delete for tenants. Delete might be the wrong term here but "make data inaccessible" is a bit clunky. I think something regulatory plays a role here but essentially one requirement this can address is to quickly and reliably make a tenants data inaccessible (by deleting the encryption key). I think this probably shouldn't be labeled as encryption in the sense of keeping data confidential in the presence of adversarial agents, but rather encryption can be looked at as a means to an end...safely deleting data at a certain time.
So, yes. Dynamic multi-tenancy. This includes the ability to provision but also deprovision differently encrypted namespaces. Doing this at the full pool (consisting of dedicated OSDs) level is too coarse. It'd require significant overhead in terms of OSD layout/deployment, CRUSH map editing etc. Pools in general are a fairly clunky concept in Ceph. If all my tenants have similar redundancy needs but aren't supposed to share the same namespace and have different data amounts, I don't want a million pools. Hence, namespaces as a more lightweight construct (even if there's parts missing that make namespaces truly useful as "virtual pools", there's hopefully more coming ;-). There's a minor benefit for tenant isolation - if, by accident, data is exposed, unless the client also supplied the right key as part of their CephX auth, perhaps they can't access it. So even if they steal the OSD key, maybe they've not stolen the tenant key. But that's somewhat of a thinner security blanket rather than an actual bunker. Though I'd like to submit for consideration that Amazon's S3 "SSE" threat model is pretty much similar. As for client side encryption: that is, indeed, an option. It's not mutually exclusive. But from what I understand, not necessarily easier, and requires modifying all clients and making sure they're compatible. (For RBD, btw, this can be done via storage classes in k8s, which can be independently encrypted. But this is exclusive access, not shared data.) For shared file (CephFS), which is our key focus here so far, client side encryption would be hard - and file/directory names and attribute values can easily be considered risky data. (None of the encrypted file system layers supports a shared file system underneath.) We could fairly easily stand up an MDS set that's pointed at a (potentially encrypted) dedicated namespace though. Also, if the performance needs otherwise require unencrypted data, this allows for encrypting only a subset of data w/o full OSD encryption. I understand and agree that it's not perfectly as awesome as full, consistent client-side encryption for everything. After long discussions, though, this is better than the current status, and seemed less difficult than full client side encryption, while ticking all the customer requirements and regulatory arguments. If we can more easily add the client-side encryption to the RADOS client protocol (so it works consistently with RBD, CephFS data and metadata paths, RGW, etc), that'd be awesome. I think. Regards, Lars -- SUSE Software Solutions Germany GmbH, MD: Felix Imendörffer, HRB 36809 (AG Nürnberg) "Architects should open possibilities and not determine everything." (Ueli Zbinden)