We need to document the architecture and capabilities of Ceph's at-rest encryption feature. Topics to cover: 1. How dm-crypt works and how it benefits the admin/end-user. 2. How OSDs interact with dm-crypt during installation, initialization, etc 3. How keys are handled.
Alright, thanks for the clarification Neil. I thought this was documented already and the "at-rest" misled me. Bara, answer below: 2. During the OSD installation, for a collocated scenario (journal and ceph data on the same disk), ceph-disk creates 3 partitions: "ceph data", "ceph journal" and a tiny " ceph lockbox" (10M). The lockbox partition holds a couple of files, such as the key used by the client.osd-lockbox user to retrieve LUKS private key. Both data and journal partitions are encrypted. Later, cryptsetup sets up two dm-crypt devices in LUKS for both "ceph data" and "ceph journal" partitions. dm-crypt devices are identified by the respective partition guid of "ceph data" and "ceph journal". 3. LUKS Keys are stored in key/value store of the Ceph monitors. Each OSD has its own key. Those keys are used to "open" the dmcrypt device so that device can be accessed and the filesystem mounted. Hope it's clear :).
Isn't this a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1325745?
Sounds good to me :)
Answering the questions here: Question: do the partition names really include spaces? Shouldn’t it be ceph_data or ceph-data? Yes they have space, these are partition labels. Question: Is the client.osd-lockbox user a cephfx user? How does this work together? Does Ansible create that user?Question: How does this work when data and journal are on not collocated? Yes it's a cephx user. ceph-disk creates the user. This is identical when there is a dedicated device for the journal, the journal partition gets encrypted as well. Same mechanism. Question: what if I restart the encrypted OSD node? Am I going to be prompted for a password? How this is handled? No password required for the restart the partition stays open. Question: Do we have any recommended/best practices? Best practices for?
Question: when do I need to list and access the keys? Do I need to copy them for example to a newly added monitor? What is the use case for this? We don't need to do anything with those keys. This key is the LUKS key used to encrypt the device. Question: Any recommendation/best practices? (Context: This comes from "Describe how to store dm-crypt keys (dmcrypt-key-dir) and any relevant guidelines/recommendations, etc." in the content plan dm-crypt keys are stored on the monitors kv store so we are good.
Yes remove the list and get keys from the doc :)
LGTM, thanks Bara!
Bara, I removed the LUKS part which is not necessary. LGTM as is now.