On 01/28/2016 03:53 PM, Sage Weil wrote: > On Thu, 28 Jan 2016, Joshua Schmid wrote: >> >> Hi Sage, >> >> On 01/27/2016 03:26 PM, Sage Weil wrote: >>> We've had several partial starts to address this problem but haven't >>> gotten anything over the line. A quick summary: >>> >>> 1- Currently we store dm-crypt keys in /etc/ceph/dmcrypt-keys/$osd_uuid, >>> on the boot disk. This lets you throw away OSD disk but not boot disks >>> and doesn't help you if someone walks away with a whole server. >>> >>> 2- SUSE had a pull request that made ceph-disk push/pull keys over (s)ftp. >>> I can't find it now.. did it get closed? >> >> It's here. >> >> https://github.com/SUSE/ceph/commit/0f5644ef3d1b1a9a14be97717b9d8dfe0338b74d >> >>> >>> I suggest we do something simple: >>> >>> 1- Update SUSE's ceph-disk changes to make it easy to plug in >>> different key management strategies. >> >> And there. >> >> https://github.com/SUSE/ceph/commit/127a47ca7cf28f387d832da265f6955bb04107c3 > > Thanks! > >> SUSE currently sticks with this solution since its pluggable and works >> fairly well. It may not be the cleanest solution to rely on an external >> tool(ftp) but until now there is simply no other option. >> >>> 2- Implement a simple mon-based strategy upstream. We've discussed this a >>> fair bit in the past, and were getting stuck on the problem of where to >>> store the key-fetching-key. I.e., we want a key on the disk that you use >>> to ask the monitor for the LUKS key, which you then provide to LUKS to >>> unlock the actual encryption key. This means that we need a unencrypted >>> spot on the device to store it in. Milan has indicated that putting it in >>> a LUKS key slot would be a bad idea and difficult to maintain. Instead, I >>> propose we create a new GPT partition type called OSD_LOCKBOX (or >>> similar), with a tiny filesystem and a few files indicating what to do. >>> This will make it easy to store the info we need for the mon scheme, and >>> to support new key management approaches later (we can put whatever we >>> want there as long as it's not too big). >> >> Sounds good! But i still see the possible scenario where you dump a >> whole rack with a MON + OSD. As a potential attacker, having these two >> components would grant you access to all the keys needed to decrypt the >> OSDdata. If I got understood it correctly that every MON should hold all >> available keys. > > I think this is no different than a normal keyserver: if you steal the > encrypted thing, and the keyserver, then the game is up. In this case the > mon is just acting as a keyserver. > > Unless there are other tricks that the keyservers normally play? The only difference between a dedicated keyserver and a MON is that you hopefully know where its physically located and can take precautions. So the problem(customer needs) we are facing is not only theft but the ability to just dump disks/nodes/racks without exposing sensitive data. > >> Some additions: >> >> The MON should only hand out keys when authenticated or in a clean >> cluster context. So what i mean is basically some way to proof if the >> MON is not in a made up environment. > > Like, a secret to decrypt the keyservers' keys might be erasure coded > across the keyservers so that you can only decrypt when you have a quorum? > sounds pretty good to me! that would cover all requirements i can currently think of.. > sage > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Freundliche Grüße - Kind regards, Joshua Schmid SUSE Enterprise Storage - Trainee SUSE Linux GmbH - Maxfeldstr. 5 - 90409 Nürnberg -------------------------------------------------------------------------------------------------------------------- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) -------------------------------------------------------------------------------------------------------------------- -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
