On Sat, May 27, 2023 at 5:09 AM Alexander E. Patrakov <patrakov@gmail.com> wrote:
Hello Frank,
On Fri, May 26, 2023 at 6:27 PM Frank Schilder <frans@dtu.dk> 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@heinlein-support.de> Sent: Tuesday, May 23, 2023 6:35 PM To: ceph-users@ceph.io Subject: [ceph-users] Re: Encryption per user Howto
On 23.05.23 08:42, huxiaoyu@horebdata.cn 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@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
-- Alexander E. Patrakov
-- Alexander E. Patrakov