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

[Loic Dachary <loic@dachary.org>]

Hi Joshua,

Is there an issue related to your changes in http://tracker.ceph.com/ or would you like me to create one ?

Cheers

On 28/01/2016 16:44, Joshua Schmid wrote:
> 
> Hi Sage,
> 
> 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?
> 
> It's here.
> 
> https://github.com/SUSE/ceph/commit/0f5644ef3d1b1a9a14be97717b9d8dfe0338b74d
> 
>>
>> I suggest we do something simple:
>>
>> 1- Update SUSE's ceph-disk changes to make it easy to plug in 
>> different key management strategies.
> 
> And there.
> 
> https://github.com/SUSE/ceph/commit/127a47ca7cf28f387d832da265f6955bb04107c3
> 
> SUSE currently sticks with this solution since its pluggable and works
> fairly well. It may not be the cleanest solution to rely on an external
> tool(ftp) but until now there is simply no other option.
> 
>>
>> 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.
> 
> 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.
> 
> 
>>
>> I put some notes here:
>>
>> 	http://pad.ceph.com/p/osd-key-management
>>
>> Thoughts?
>> 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
>>
> 

-- 
Loïc Dachary, Artisan Logiciel Libre
--
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