Hi, Thanks for your good comeback! > to your KSS -; Shinobu ----- Original Message ----- From: "Joshua Schmid" <jschmid@xxxxxxx> To: skinjo@xxxxxxxxxx, "Sage Weil" <sage@xxxxxxxxxxxx> Cc: "Ceph Development" <ceph-devel@xxxxxxxxxxxxxxx> Sent: Friday, August 28, 2015 5:11:34 PM Subject: Re: Proposal: data-at-rest encryption On 08/28/2015 01:32 AM, Shinobu wrote: > Hello, > > Just question. > If the key is broken, how could ceph (maybe named kss standing for key > store server :0) recover, and where information to restore it could be > retrieved? > Any blueprint? Hi, i don't know if i got your question right. Are you asking what ceph will do if the keyserver is down and where to get the information from on how to restore the OSD? Well, there will be a timeout if the KSS is unreachable. But in a productive environment it might not be a bad idea to add HA to your KSS. > > Shinobu > > On Thu, Aug 27, 2015 at 10:38 PM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > >> On Thu, 27 Aug 2015, Joshua Schmid wrote: >>> >>> On 08/27/2015 02:49 AM, Sage Weil wrote: >>>> Hi Joshua! >>>> >>> >>> Hi Sage, >>> >>> >>>> Overall the ceph-disk changes look pretty good, and it looks like >> Andrew >>>> and David have both reviewed. My only real concern/request is that the >>>> key server be as pluggable as possible. You're using ftps here, but >> we'd >>>> also like to allow deo[1], or even the mon config-key service. >>> >>> Thank for having a look! >>> I think this should do: >>> >>> >> https://github.com/jschmid1/ceph/commit/7dd64c70bcb8d986568d6f379a6fbf9a0e40a441 >>> >>> Service of choice can now be set in the ceph.conf and will be handled >>> separately. This is currently only for unlocking/mapping but will be >>> extended for locking/new if this solution is acceptable. >> >> Yep! It'd probably be much cleaner to wrap this up in a class with >> fetch_key() and create_key(), etc. methods so that there is only one place >> that has to instantiate the implemetnation based on type. >> >>>> With the original mon proposal, we also wanted an additional layer of >>>> security (beyond simply access to the storage network) by >>>> storing some key-fetching-key on the disk. >>> >>> Like deo does it? (From the deo README) >>> >>> """ >>> Second, we will add a new random key to the pre-existing LUKS encrypted >>> disk and then encrypt it using Deo in a known location. >>> """ >>> >>> >>> It looks like the ftps >>>> access is unauthenticated... is that right? I would assume (I'm not >> hte >>>> expert!) that most key management systems require some credentials to >>>> store/fetch keys? >>> >>> Its totally unauthenticated, thats right. It'd be possible to require >>> USER/PASS for ftp. >> >> Yeah. If we have a general method to store a key-fetching-key on the disk >> (in the LUKS table? I forget if this was practical) on the LUKS disk the >> might work? Hopefully such that various backends can all use it (e.g., as >> the ftps password, or as a mon key).. >> >> 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 Trainee - Storage 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
