It's http://tracker.ceph.com/issues/14669 On 05/02/2016 17:13, Loic Dachary wrote: > 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
