On 08/27/2015 03:38 PM, Sage Weil 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. > I dont know if i understood you correctly here. But, since ceph-disk is classless wouldn't it be a bit strange to introduce one? I now put anything associated with fetching/creating key in a seperate method retrieve_key() and create_key() which will behave accordingly. >>> 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).. I guess putting it in the LuksKeySlot[1] might work. But plain-dmcrypt has to be handled differently then. For compatibility reasons i suggest to avoid that. But storing it on the root partition is not a good idea either. This area definitely needs more heavy thinking.. > > 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
