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
