On Sat, May 27, 2023 at 5:09 AM Alexander E. Patrakov <patrakov@xxxxxxxxx> wrote: > > Hello Frank, > > On Fri, May 26, 2023 at 6:27 PM Frank Schilder <frans@xxxxxx> wrote: > > > > Hi all, > > > > jumping on this thread as we have requests for which per-client fs mount encryption makes a lot of sense: > > > > > What kind of security to you want to achieve with encryption keys stored > > > on the server side? > > > > One of the use cases is if a user requests a share with encryption at rest. Since encryption has an unavoidable performance impact, it is impractical to make 100% of users pay for the requirements that only 1% of users really have. Instead of all-OSD back-end encryption hitting everyone for little reason, encrypting only some user-buckets/fs-shares on the front-end application level will ensure that the data is encrypted at rest. > > > > I would disagree about the unavoidable performance impact of at-rest > encryption of OSDs. Read the CloudFlare blog article which shows how > they make the encryption impact on their (non-Ceph) drives negligible: > https://blog.cloudflare.com/speeding-up-linux-disk-encryption/. The > main part of their improvements (the ability to disable dm-crypt > workqueues) is already in the mainline kernel. There is also a Ceph > pull request that disables dm-crypt workqueues on certain drives: > https://github.com/ceph/ceph/pull/49554 > > While the other part of the performance enhancements authored by > CloudFlare (namely, the "xtsproxy" module) is not mainlined yet, I > hope that some equivalent solution will find its way into the official > kernel sooner or later. > > In summary: just encrypt everything. As a follow-up, if you disagree with the advice to encrypt everything, please note that CephFS allows one to place certain directories on a separate pool. Therefore, you can create a separate device class for encrypted OSDs, create a pool that uses this device class, and put the directories owned by your premium users onto this pool. Documentation: https://docs.ceph.com/en/latest/cephfs/file-layouts/ > > > It may very well not serve any other purpose, but these are requests we get. If I could provide an encryption key to a ceph-fs kernel at mount time, this requirement could be solved very elegantly on a per-user (request) basis and only making users who want it pay with performance penalties. > > > > Best regards, > > ================= > > Frank Schilder > > AIT Risø Campus > > Bygning 109, rum S14 > > > > ________________________________________ > > From: Robert Sander <r.sander@xxxxxxxxxxxxxxxxxxx> > > Sent: Tuesday, May 23, 2023 6:35 PM > > To: ceph-users@xxxxxxx > > Subject: Re: Encryption per user Howto > > > > On 23.05.23 08:42, huxiaoyu@xxxxxxxxxxxx wrote: > > > Indeed, the question is on server-side encryption with keys managed by ceph on a per-user basis > > > > What kind of security to you want to achieve with encryption keys stored > > on the server side? > > > > Regards > > -- > > Robert Sander > > Heinlein Support GmbH > > Linux: Akademie - Support - Hosting > > http://www.heinlein-support.de > > > > Tel: 030-405051-43 > > Fax: 030-405051-19 > > > > Zwangsangaben lt. §35a GmbHG: > > HRB 93818 B / Amtsgericht Berlin-Charlottenburg, > > Geschäftsführer: Peer Heinlein -- Sitz: Berlin > > _______________________________________________ > > ceph-users mailing list -- ceph-users@xxxxxxx > > To unsubscribe send an email to ceph-users-leave@xxxxxxx > > _______________________________________________ > > ceph-users mailing list -- ceph-users@xxxxxxx > > To unsubscribe send an email to ceph-users-leave@xxxxxxx > > > > -- > Alexander E. Patrakov -- Alexander E. Patrakov _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |