Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
64 changes: 56 additions & 8 deletions source/adminguide/storage.rst
Original file line number Diff line number Diff line change
Expand Up @@ -621,16 +621,64 @@ Instances with local data volumes on that host.
Volume Encryption
^^^^^^^^^^^^^^^^^

CloudStack supports LUKS-based volume encryption on KVM. Encrypted volumes are managed
through the :ref:`key-management-system`, where you can create and manage the encryption
keys used to protect your data.

To create an encrypted volume, select a **KMS Key** from the UI when creating the volume,
or supply the key ID via the API. The key must belong to the same zone as the volume.
CloudStack supports LUKS-based volume encryption on KVM. Encryption is enabled through the
storage offering: create a Disk Offering with encryption enabled (for data volumes) or a
Compute Offering with root volume encryption enabled (for root disks), and deploy on a
primary storage that supports encryption. Volumes deployed from such an offering are
encrypted automatically with a per-volume passphrase. Encryption is performed on the KVM
host, so the guest always sees a normal, decrypted disk and there is no encryption device
to manage inside the Instance.

By default the per-volume passphrase is protected by a single key stored in the database.
Optionally, the :ref:`key-management-system` (KMS, introduced in 4.23) can instead wrap the
passphrase with a key held in an external HSM/KMS provider, in which case you select a
**KMS Key** for the volume. KMS is not required for volume encryption.

This choice of key protection is independent of the storage backend: every
encryption-capable backend, including Ceph/RBD, works with either the database key or a KMS
key. The encryption engine on the KVM host uses the resulting per-volume passphrase and does
not depend on how that passphrase was protected, so no storage-specific configuration is
needed to use one method or the other.

.. warning::
Deleting the KMS key used to encrypt a volume will render that volume permanently
unrecoverable.
If the key material protecting a volume's passphrase is lost — for example by deleting
the KMS key used to wrap it — that volume becomes permanently unrecoverable.

Supported primary storage
~~~~~~~~~~~~~~~~~~~~~~~~~~~

* File-based storage (NFS, local, SharedMountPoint) and Dell PowerFlex/ScaleIO — encrypted
with the qemu-native LUKS stack.
* Ceph/RBD — encrypted with **native librbd LUKS2**
(``<encryption format='luks2' engine='librbd'>``), for both data disks and root disks.

The two stacks are not interchangeable: a volume is always decrypted by the same engine
that encrypted it, and they are never mixed on a single volume.

Ceph/RBD encryption
~~~~~~~~~~~~~~~~~~~

For Ceph/RBD, encryption is applied natively by librbd, which preserves Ceph's thin
provisioning and copy-on-write cloning:

* **Data disks** stay thin — only written blocks consume space (a 1 TB encrypted volume
with 400 GB written uses roughly 400 GB).
* **Root disks** deployed from a template already on the same Ceph cluster are created as
thin copy-on-write clones: each Instance stores only its own (encrypted) writes and
shares the template blocks, so deploying many encrypted Instances from one template uses
far less storage than a full per-Instance copy. When the template is not on the same
cluster (for example on first use from secondary storage), the encrypted root is created
as a full copy instead.

.. note::
Attaching an encrypted RBD volume to a **running** Instance (hot-plug) requires
**libvirt >= 10.1.0** on the KVM host. Older libvirt (for example 10.0.0 shipped with
Ubuntu 24.04 LTS) has a bug that breaks hot-plug of encrypted block devices; on such a
host the CloudStack agent refuses the attach with a clear error. Booting an Instance
from an encrypted RBD root disk is **not** affected and works on older libvirt.

Requirements on the KVM host: ``ceph-common`` (the ``rbd`` CLI) and a QEMU/librbd build
that supports librbd LUKS2 encryption (Ceph Pacific / QEMU 6.1 and newer).


To Create a New Volume
Expand Down
Loading