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

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

[Joshua Schmid]

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
> 

-- 
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

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

[Loic Dachary]

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

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

[Sage Weil]

On Thu, 28 Jan 2016, 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

Thanks!

> 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.

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?

> 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?

sage

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

[Joshua Schmid]

On 01/28/2016 03:53 PM, Sage Weil wrote:
> On Thu, 28 Jan 2016, 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
> 
> Thanks!
> 
>> 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.
> 
> 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..

> 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

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

[Sage Weil]

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.

sage

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

[Joshua Schmid]

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

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

[Loic Dachary]

I'll go ahead and create one then ;-)

On 28/01/2016 19:00, Loic Dachary wrote:
> 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

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

[Loic Dachary]

It's http://tracker.ceph.com/issues/14669

On 05/02/2016 17:13, Loic Dachary wrote:
> I'll go ahead and create one then ;-)
> 
> On 28/01/2016 19:00, Loic Dachary wrote:
>> 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