Skip to content

Commit 82cb1e6

Browse files
committed
storage: document RBD/Ceph (librbd LUKS2) volume encryption
Rework the Volume Encryption admin-guide section to describe the offering-based enablement (an encrypted Disk/Compute Offering) as the primary mechanism, with KMS as an optional passphrase-wrapping layer rather than the only path. Add the supported primary-storage backends and the Ceph/RBD librbd LUKS2 specifics: thin provisioning, copy-on-write encrypted root clones, the libvirt >= 10.1.0 hot-plug requirement, and the KVM host requirements.
1 parent da5cf24 commit 82cb1e6

1 file changed

Lines changed: 50 additions & 8 deletions

File tree

source/adminguide/storage.rst

Lines changed: 50 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -621,16 +621,58 @@ Instances with local data volumes on that host.
621621
Volume Encryption
622622
^^^^^^^^^^^^^^^^^
623623

624-
CloudStack supports LUKS-based volume encryption on KVM. Encrypted volumes are managed
625-
through the :ref:`key-management-system`, where you can create and manage the encryption
626-
keys used to protect your data.
627-
628-
To create an encrypted volume, select a **KMS Key** from the UI when creating the volume,
629-
or supply the key ID via the API. The key must belong to the same zone as the volume.
624+
CloudStack supports LUKS-based volume encryption on KVM. Encryption is enabled through the
625+
storage offering: create a Disk Offering with encryption enabled (for data volumes) or a
626+
Compute Offering with root volume encryption enabled (for root disks), and deploy on a
627+
primary storage that supports encryption. Volumes deployed from such an offering are
628+
encrypted automatically with a per-volume passphrase. Encryption is performed on the KVM
629+
host, so the guest always sees a normal, decrypted disk and there is no encryption device
630+
to manage inside the Instance.
631+
632+
By default the per-volume passphrase is protected by a single key stored in the database.
633+
Optionally, the :ref:`key-management-system` (KMS, introduced in 4.23) can instead wrap the
634+
passphrase with a key held in an external HSM/KMS provider, in which case you select a
635+
**KMS Key** for the volume. KMS is not required for volume encryption.
630636

631637
.. warning::
632-
Deleting the KMS key used to encrypt a volume will render that volume permanently
633-
unrecoverable.
638+
If the key material protecting a volume's passphrase is lost — for example by deleting
639+
the KMS key used to wrap it — that volume becomes permanently unrecoverable.
640+
641+
Supported primary storage
642+
~~~~~~~~~~~~~~~~~~~~~~~~~~~
643+
644+
* File-based storage (NFS, local, SharedMountPoint) and Dell PowerFlex/ScaleIO — encrypted
645+
with the qemu-native LUKS stack.
646+
* Ceph/RBD — encrypted with **native librbd LUKS2**
647+
(``<encryption format='luks2' engine='librbd'>``), for both data disks and root disks.
648+
649+
The two stacks are not interchangeable: a volume is always decrypted by the same engine
650+
that encrypted it, and they are never mixed on a single volume.
651+
652+
Ceph/RBD encryption
653+
~~~~~~~~~~~~~~~~~~~
654+
655+
For Ceph/RBD, encryption is applied natively by librbd, which preserves Ceph's thin
656+
provisioning and copy-on-write cloning:
657+
658+
* **Data disks** stay thin — only written blocks consume space (a 1 TB encrypted volume
659+
with 400 GB written uses roughly 400 GB).
660+
* **Root disks** deployed from a template already on the same Ceph cluster are created as
661+
thin copy-on-write clones: each Instance stores only its own (encrypted) writes and
662+
shares the template blocks, so deploying many encrypted Instances from one template uses
663+
far less storage than a full per-Instance copy. When the template is not on the same
664+
cluster (for example on first use from secondary storage), the encrypted root is created
665+
as a full copy instead.
666+
667+
.. note::
668+
Attaching an encrypted RBD volume to a **running** Instance (hot-plug) requires
669+
**libvirt >= 10.1.0** on the KVM host. Older libvirt (for example 10.0.0 shipped with
670+
Ubuntu 24.04 LTS) has a bug that breaks hot-plug of encrypted block devices; on such a
671+
host the CloudStack agent refuses the attach with a clear error. Booting an Instance
672+
from an encrypted RBD root disk is **not** affected and works on older libvirt.
673+
674+
Requirements on the KVM host: ``ceph-common`` (the ``rbd`` CLI) and a QEMU/librbd build
675+
that supports librbd LUKS2 encryption (Ceph Pacific / QEMU 6.1 and newer).
634676

635677

636678
To Create a New Volume

0 commit comments

Comments
 (0)