On 2020-08-06T18:55:29, Jan Fajerski <jfajerski@xxxxxxxx> 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)
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
