On 20/08/04 01:12PM, Josh Durgin wrote: > On 8/4/20 10:02 AM, Jason Dillaman wrote: > > On Tue, Aug 4, 2020 at 11:55 AM Joao Eduardo Luis <joao@xxxxxxx> wrote: > > > > > > On 20/08/04 09:04AM, Jason Dillaman wrote: > > > > On Mon, Aug 3, 2020 at 4:48 PM Joao Eduardo Luis <joao@xxxxxxx> 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. This is the main driver for this proposal, actually. Indeed, having a policy of some pools going into dmcrypted osds vs others going into non-encrypted osds works. However, the problem we've been seeing is that there's demand for encrypting those pools per-tenant, with different keys; some of this may have legal implications. Now, the real issue is not with being unable to achieve this with pools, but the scale. Mapping a handful of tenants to specific pools may be feasible, but go a bit above that and you will end up with a complex crush hierarchy, and maybe not enough osds to ensure the mentioned requirements. And you'd end up with a lot of (potentially small) pools. The idea of encrypting namespaces instead aims at addressing this scenario. -Joao _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
