I'll go ahead and create one then ;-) On 28/01/2016 19:00, Loic Dachary wrote: > Hi Joshua, > > Is there an issue related to your changes in http://tracker.ceph.com/ or would you like me to create one ? > > Cheers > > On 28/01/2016 16:44, 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 >> >> 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. >> >> 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. >> >> >>> >>> I put some notes here: >>> >>> http://pad.ceph.com/p/osd-key-management >>> >>> Thoughts? >>> 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 >>> >> > -- Loïc Dachary, Artisan Logiciel Libre -- 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
