]>
Commit | Line | Data |
---|---|---|
b32b8144 FG |
1 | .. _ceph-volume-lvm-encryption: |
2 | ||
3 | Encryption | |
4 | ========== | |
5 | ||
6 | Logical volumes can be encrypted using ``dmcrypt``. Encryption can be done in | |
7 | different ways, specially with LVM. ``ceph-volume`` is somewhat opinionated | |
8 | with the way it sets up encryption with logical volumes so that the process is | |
9 | consistent and robust. | |
10 | ||
11 | In this case, ``ceph-volume lvm`` follows these constraints: | |
12 | ||
13 | * only LUKS (version 1) is used | |
14 | * Logical Volumes are encrypted, while their underlying PVs (physical volumes) | |
15 | aren't | |
16 | * Non-LVM devices like partitions are also encrypted with the same OSD key | |
17 | ||
18 | ||
19 | LUKS | |
20 | ---- | |
21 | There are currently two versions of LUKS, 1 and 2. Version 2 is a bit easier | |
22 | to implement but not widely available in all distros Ceph supports. LUKS 1 is | |
23 | not going to be deprecated in favor of LUKS 2, so in order to have as wide | |
24 | support as possible, ``ceph-volume`` uses LUKS version 1. | |
25 | ||
26 | .. note:: Version 1 of LUKS is just referenced as "LUKS" whereas version 2 is | |
27 | referred to as LUKS2 | |
28 | ||
29 | ||
30 | LUKS on LVM | |
31 | ----------- | |
32 | Encryption is done on top of existing logical volumes (unlike encrypting the | |
33 | physical device). Any single logical volume can be encrypted while other | |
34 | volumes can remain unencrypted. This method also allows for flexible logical | |
35 | volume setups, since encryption will happen once the LV is created. | |
36 | ||
37 | ||
38 | Workflow | |
39 | -------- | |
40 | When setting up the OSD, a secret key will be created, that will be passed | |
41 | along to the monitor in JSON format as stdin to prevent the key from being | |
42 | captured in the logs. | |
43 | ||
44 | The JSON payload looks something like:: | |
45 | ||
46 | { | |
47 | "cephx_secret": CEPHX_SECRET, | |
48 | "dmcrypt_key": DMCRYPT_KEY, | |
49 | "cephx_lockbox_secret": LOCKBOX_SECRET, | |
50 | } | |
51 | ||
52 | The naming convention for the keys is **strict**, and they are named like that | |
53 | for the hardcoded (legacy) names ceph-disk used. | |
54 | ||
55 | * ``cephx_secret`` : The cephx key used to authenticate | |
56 | * ``dmcrypt_key`` : The secret (or private) key to unlock encrypted devices | |
57 | * ``cephx_lockbox_secret`` : The authentication key used to retrieve the | |
58 | ``dmcrypt_key``. It is named *lockbox* because ceph-disk used to have an | |
59 | unencrypted partition named after it, used to store public keys and other | |
60 | OSD metadata. | |
61 | ||
62 | The naming convention is strict because Monitors supported the naming | |
63 | convention by ceph-disk, which used these key names. In order to keep | |
64 | compatibility and prevent ceph-disk from breaking, ceph-volume will use the same | |
65 | naming convention *although they don't make sense for the new encryption | |
66 | workflow*. | |
67 | ||
68 | After the common steps of setting up the OSD during the prepare stage, either | |
69 | with :term:`filestore` or :term:`bluestore`, the logical volume is left ready | |
70 | to be activated, regardless of the state of the device (encrypted or decrypted). | |
71 | ||
72 | At activation time, the logical volume will get decrypted and the OSD started | |
73 | once the process completes correctly. | |
74 | ||
75 | Summary of the encryption workflow for creating a new OSD: | |
76 | ||
77 | #. OSD is created, both lockbox and dmcrypt keys are created, and sent along | |
78 | with JSON to the monitors, indicating an encrypted OSD. | |
79 | ||
80 | #. All complementary devices (like journal, db, or wal) get created and | |
81 | encrypted with the same OSD key. Key is stored in the LVM metadata of the | |
82 | OSD | |
83 | ||
84 | #. Activation continues by ensuring devices are mounted, retrieving the dmcrypt | |
85 | secret key from the monitors and decrypting before the OSD gets started. |