On 01/28/2016 06:46 PM, Sage Weil wrote: > On Thu, 28 Jan 2016, Joshua Schmid 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). >>>> >>>> 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.. > > I'm skeptical that's actually something we want to implement in the mon, > though. I think if you want that level of security (secret sharding > across keyservers) you should use a real keyserver and not the mon. I > think if we cover the basic case, though, where we assume the monitor > nodes are secure and separate from the OSDs, then that'll cover most > users' needs. Thats true. There is one more concern I have about using MONs as keyservers. Users might want to encrypt their swap/root (and i some cases I guess they have to) what means that authentication has to take place in the initrd. Pulling in a ceph-client to retrieve the keys might be a bad idea. So i guess relying on a rather small service (ftps) could be cleaner/easier. > > 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
