Re: Fwd: Re: osd dm-crypt key management, part... deux?

[Joshua Schmid <jschmid@suse.de>]

On 01/28/2016 06:46 PM, Sage Weil wrote:
> On Thu, 28 Jan 2016, Joshua Schmid wrote:
>>>>> 2- Implement a simple mon-based strategy upstream.  We've discussed this a 
>>>>> fair bit in the past, and were getting stuck on the problem of where to 
>>>>> store the key-fetching-key.  I.e., we want a key on the disk that you use 
>>>>> to ask the monitor for the LUKS key, which you then provide to LUKS to 
>>>>> unlock the actual encryption key.  This means that we need a unencrypted 
>>>>> spot on the device to store it in.  Milan has indicated that putting it in 
>>>>> a LUKS key slot would be a bad idea and difficult to maintain.  Instead, I 
>>>>> propose we create a new GPT partition type called OSD_LOCKBOX (or 
>>>>> similar), with a tiny filesystem and a few files indicating what to do.  
>>>>> This will make it easy to store the info we need for the mon scheme, and 
>>>>> to support new key management approaches later (we can put whatever we 
>>>>> want there as long as it's not too big).
>>>>
>>>> Sounds good! But i still see the possible scenario where you dump a
>>>> whole rack with a MON + OSD. As a potential attacker, having these two
>>>> components would grant you access to all the keys needed to decrypt the
>>>> OSDdata. If I got understood it correctly that every MON should hold all
>>>> available keys.
>>>
>>> I think this is no different than a normal keyserver: if you steal the 
>>> encrypted thing, and the keyserver, then the game is up.  In this case the 
>>> mon is just acting as a keyserver.
>>>
>>> Unless there are other tricks that the keyservers normally play?
>>
>> The only difference between a dedicated keyserver and a MON is that you
>> hopefully know where its physically located and can take precautions. So
>> the problem(customer needs) we are facing is not only theft but the
>> ability to just dump disks/nodes/racks without exposing sensitive data.
>>
>>
>>>
>>>> Some additions:
>>>>
>>>> The MON should only hand out keys when authenticated or in a clean
>>>> cluster context. So what i mean is basically some way to proof if the
>>>> MON is not in a made up environment.
>>>
>>> Like, a secret to decrypt the keyservers' keys might be erasure coded 
>>> across the keyservers so that you can only decrypt when you have a quorum?
>>>
>> sounds pretty good to me! that would cover all requirements i can
>> currently think of..
> 
> I'm skeptical that's actually something we want to implement in the mon, 
> though.  I think if you want that level of security (secret sharding 
> across keyservers) you should use a real keyserver and not the mon.  I 
> think if we cover the basic case, though, where we assume the monitor 
> nodes are secure and separate from the OSDs, then that'll cover most 
> users' needs.

Thats true. There is one more concern I have about using MONs as
keyservers. Users might want to encrypt their swap/root (and i some
cases I guess they have to) what means that authentication has to take
place in the initrd. Pulling in a ceph-client to retrieve the keys might
be a bad idea. So i guess relying on a rather small service (ftps) could
be cleaner/easier.

> 
> sage
> 
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Freundliche Grüße - Kind regards,
Joshua Schmid
SUSE Enterprise Storage - Trainee
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html