On Thu, Dec 14, 2017 at 8:49 AM, Milan Broz <mbroz@xxxxxxxxxx> wrote: > On 12/14/2017 02:17 PM, Alfredo Deza wrote: >>>> Standard Fedora (and most other distors as well) install stacks LVM over LUKS >>>> (so you activate only one encrypted device and then the partitioning is up to LVM. >>>> Also LVM metadata are then encrypted.) >> >> That is a very important distinction (encrypted LVM metadata) and why >> we don't want to go that route: we rely heavily on LVM metadata where >> we store the >> information about the OSD to be later queried. That metadata must be >> available without decryption. > > LUKS2 allows you to store store your JSON data to LUKS header. > For the identification of OSD or whatever you need it is even simpler. > >>> The problem I see is that we frequently carve up a single phsycial device >>> across lots of OSDs (usually for the journal or wal/db), and the key >>> management is currently structured around OSDs, not devices. We can >>> either (1) switch it all around so the key management is based on physical >>> devices instead of OSDs, or (2) carve the physical device into raw LVs, >>> dm-crypt those, and then consume the result. >> >> #2 here is my preference. Lets not switch key management around. I >> don't know how things like dmcache >> (which is made up of several physical devices) would work for option #1. > > I currently lost overview what is Ceph doing, but for unlocking > of crypt device - LUKS2 allows you to store passphrase to kernel keyring > (in advance) and then device is unlocked automatically. > (It needs to configure a "token" for metadata - in the case of keyring > it is just name in keyring.) Do you have docs that explain this bit in detail? We were just going to do what was done already by ceph-disk, that differs a lot from the kernel keyring workflow. > > Maybe it can simplify your key management in future with LUKS. > > (LUKS2 is already in Fedora rawhide and in some experimental repos of other distros. > It need some time to be widely used and I know it will need some fixes - but in principle > things mentioned above already work.) That is a big gotcha though, we would need 100% availability in the distros/versions we support at release time (around April-May 2018) Are you leaning towards encrypting the physical devices over encrypting LVs ? I'm not seeing any risks so far in just going the lv encryption route (yet) > > Milan -- 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
