That's a great idea, it simplifies things for the admin and doesn't sound too hairy on the monitor side. One alternative option is to do it in one of the ways that ZFS does; that is you can provide a config option that says 'get the keys from here'. For example you could set up an https server and have ceph fetch the keys from it at start up. Users could provide a master key for the whole pool, or per OSD, or different keys for groups of OSDs, per the config file.
I still like the monitor idea better, but different users may prefer different methods, and this might be an easier solution to implement first. Here's some of the zfs documentation in case it sparks some other ideas. # zfs create -o encryption=on -o keysource=raw,https://keys.example.com/mykey tank/project/R http://www.oracle.com/technetwork/articles/servers-storage-admin/manage-zfs-encryption-1715034.html On Thu, Jan 31, 2013 at 5:04 PM, Mark Kampe <mark.ka...@inktank.com> wrote: > Correct. > > I wasn't actually involved in this (or any other real) work, > but as I recall the only real trick is how much key management > you want: > > Do we want to be able to recover the key if a good disk > is rescued from a destroyed server and added to a new > server? > > Do we want to ensure that the keys are not persisted on > the server, so that an entire server can be decommissioned > without having to worry about the data being recovered > by somebody who knows where to look? > > If you are willing to keep the key on the server and lose > the data when the server fails, this is trivial. If you > are unwilling to keep the key on the server, or if you need > the disk to remain readable after the server is lost, we > need some third party (like the monitors) to maintain the > keys. > > We thought these might be important, so we were looking > at how to get the monitors to keep track of the encryption > keys. > > > On 01/31/2013 03:42 PM, Marcus Sorensen wrote: >> >> Yes, anyone could do this now by setting up the OSDs on top of >> dm-crypted disks, correct? This would just automate the process, and >> manage keys for us? > > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
