Virt guest disk image encryption use cases
From FedoraProject
The low-level functionality is also available through virsh, but it's not expected users will access it that way.
Contents |
Using a management server
Creating an encrypted volume
This applies both to creating volumes stand-alone, and as a part of creating a guest.
- The system administrator checks an "encrypted volume" checkbox when creating the volume. The selected volume format must support encryption. Other encryption parameters (cipher, key length, ...) may or may not be modifiable.
- The management server generates a key, and stores it in its volume configuration.
- The management server asks a host to create the volume, supplying the key along with other information about the volume. The host does not store the key after creating the volume.
- (The management server could create the volume directly, if the network architecture supports it.)
Setting up a guest that uses an encrypted volume
- The management server collects encryption keys for all volumes used by the guest from the server's volume configuration.
- The management server sets up the guest on the destination host, supplying the keys along with other information. The host stores the keys, attached to the guest (not to the volumes).
- (The host can start the guest without any further communication with the management server.)
Destroying a guest that uses an encrypted volume
- The management server asks the host to destroy a guest.
- The host does so, and deletes all keys attached to the guest, along with other configuration.
Migrating a guest
This is conceptually similar to setting up a guest on the destination host, and destroying the guest on the source host: the management server ensures volume key availability on the destination, and the source host deletes the keys after migration.
Changing the data encryption key
(This assumes re-encryption support in LVM crypt.)
- (Initiated manually by system administrator, automatically after a policy-specified time, or automatically after a migration).
- The management server verifies the concurrent access limitations are not violated (e.g. the volume is not used by two separate hosts, or no guest using the volume is running - depending on the specific limitations of the volume format).
- The management server generates a new key, and stores it in the volume configuration.
- The management server asks a host to re-encrypt the volume, supplying the old and new key from the server's volume configuration.
- (The management server could create the volume directly, if the network architecture supports it.)
- The management server keeps enforcing the concurrent access limitations, and polls for re-encryption completion.
- The host does not store the keys after re-encrypting the volume (but it keeps the old copies attached to guests).
- The management server sends new keys to all hosts that store information about guests that use the volume (by sending them updated guest configurations that contain the new keys).
Using virt-manager and other virt-* tools
Using virt-manager should behave similarly to the above-described set up with a system management server: each virt-manager configuration behaves as a separate management server, with a separate database of volume keys. Managing a single host from two different virt-manager configurations will not be initially supported.
Command-line virt-* tools will share the volume key database with the local virt-manager configuration; other than a flag that corresponds to the "Encrypt this volume" checkbox, changes to the interface of these tools will probably not be necessary.
