Are you expecting the tenant to provide the key? Also how many tenants are you expecting to have? It seems like you're looking for per-object encryption and not per OSD. -Seth -----Original Message----- From: ceph-users-bounces@xxxxxxxxxxxxxx [mailto:ceph-users-bounces@xxxxxxxxxxxxxx] On Behalf Of Mark s2c Sent: Monday, March 10, 2014 3:08 PM To: Kyle Bader Cc: ceph-users@xxxxxxxxxxxxxx Subject: Re: Encryption/Multi-tennancy Thanks Kyle. I've deliberately not provided the entire picture. I'm aware of memory residency and of in-flight encryption issues. Theses are less of a problem for us. For me, it's a question of finding a reliably encrypted, OSS, at-rest setup which involves Ceph and preferably ZFS for flexibility. M On 2014 Mar 10, at 21:04, Kyle Bader wrote: >> Ceph is seriously badass, but my requirements are to create a cluster in which I can host my customer's data in separate areas which are independently encrypted, with passphrases which we as cloud admins do not have access to. >> >> My current thoughts are: >> 1. Create an OSD per machine stretching over all installed disks, then create a user-sized block device per customer. Mount this block device on an access VM and create a LUKS container in to it followed by a zpool and then I can allow the users to create separate bins of data as separate ZFS filesystems in the container which is actually a blockdevice striped across the OSDs. >> 2. Create an OSD per customer and use dm-crypt, then store the dm-crypt key somewhere which is rendered in some way so that we cannot access it, such as a pgp-encrypted file using a passphrase which only the customer knows. > >> My questions are: >> 1. What are people's comments regarding this problem (irrespective of >> my thoughts) > > What is the threat model that leads to these requirements? The story > "cloud admins do not have access" is not achievable through technology > alone. > >> 2. Which would be the most efficient of (1) and (2) above? > > In the case of #1 and #2, you are only protecting data at rest. With > #2 you would need to decrypt the key to open the block device, and the > key would remain in memory until it is unmounted (which the cloud > admin could access). This means #2 is safe so long as you never mount > the volume, which means it's utility is rather limited (archive > perhaps). Neither of these schemes buy you much more than the > encryption handling provided by ceph-disk-prepare (dmcrypted osd > data/journal volumes), the key management problem becomes more acute, > eg. per tenant. > > -- > > Kyle _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |