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.
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
