Re: LUKS encryption in OSDs (ceph-volume)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/15/2017 03:31 PM, Milan Broz wrote:
On 12/14/2017 03:00 PM, Alfredo Deza wrote:
On Thu, Dec 14, 2017 at 8:49 AM, Milan Broz <mbroz@xxxxxxxxxx> wrote:
On 12/14/2017 02:17 PM, Alfredo Deza wrote:

I currently lost overview what is Ceph doing, but for unlocking
of crypt device - LUKS2 allows you to store passphrase to kernel keyring
(in advance) and then device is unlocked automatically.
(It needs to configure a "token" for metadata - in the case of keyring
it is just name in keyring.)

Do you have docs that explain this bit in detail? We were just going
to do what was done already by ceph-disk, that differs a lot from the
kernel keyring
workflow.

I'll describe briefly the process for cryptsetup cli only, but you may achieve same using cryptsetup library as well. For reference here's the api docs: https://gitlab.com/cryptsetup/cryptsetup/wikis/API/index.html

In general kernel keyring activation's an extension for easier LUKS2 device unlocking.

Let's say you have LUKS2 device with keyslot 1 on /dev/sdx.

Add keyring token to LUKS2 header:
cryptsetup token add /dev/sdx --key-description my_key_name -S 1

(The token itself will contain only the key description and reference to keyslot(s) it may be used with. It's stored in jsom metadata area of LUKS2 header in plain text)

When you activate LUKS2 with such token it does following:

1) It'll try to activate the device using passphrase retrieved from kernel key described by "my_key_name" (kernel key type "user")

2) Only if step 1) fails (i.e. no such key in keyring or passphrase is wrong), the command will ask for passphrase the usual way.

So as long as "my_key_name" is reachable from calling process, user doesn't have to input passphrase every time he wants to unlock the device.

In fact kernel keyring in this particular case is just another source for passphrase just like key files stored in fs.

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



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux