On Wed, Jan 27, 2016 at 3:26 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: > 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). > > I put some notes here: > > http://pad.ceph.com/p/osd-key-management > > Thoughts? > sage Hello Sage, why we cannot simply fetch the LUKS key from a monitor during the mount phase? LUKS key wouldn't be stored in any file. Instead, it would be fetched to memory (RAM) and present there only for time necessary to initialize dm-crypt. Of course, code responsible for the setup must have an access to the OSD's keyring. It may be put into lockbox. Regards, Radek -- 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
