On Wed, 10 Feb 2016, Milan Broz wrote: > 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? > > > > 3- We built a generic "config-key" storage service into the monitor that > > lets you restrict access to certain key/value pairs based on your > > (cephx) authentication key, intending that the osd dm-crypt keys be stored > > there. > > My (upstream cryptsetup) plan is to have LUKS2 configurable keyslot and these > should allow plugins that can directly fetch the key for example. > > In fact proof-of-concept code was inspired by Ceph OSD use case and > allows fetching key from remote server through libssh (it expects > ssh keys configured such way, that you can run ssh to some server > with public key auth without password - but that's just example). > > In LUKS2 header then we store just ssh server/user/dir > https://gitlab.com/cryptsetup/cryptsetup/blob/wip-luks2/misc/luks2_keyslot_example/keyslot_test.c > (please note it is just wip example of standalone binary, interface will change, > and currently it uses real volume key, not unlocking passphrase) > > I can imagine that in long-term there can be simple keyslot using > cephx auth as well or whatever Ceph will need. This sounds really promising! I wish it were arriving a bit sooner... :/ > > 5- Lars observes that any solution is incomplete if we don't *also* > > encrypt the swap devices. (I think we don't need to worry about the boot > > disks, though, unless we're paranoid about /var/log/ceph?) > > It depends on your threat model... > > But you can easily create encrypted swap using key from /dev/urandom > (iow regenerated every boot). > > This is common solution if you do not store hibernation data in swap. > (Just one line in crypttab/fstab.) Good to know! Lars, does this fully address your concerns? I forget if the boot drive (and /var/log) was part of your concern. 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
