Description of problem:
feature request: it would be great if virt-builder would support creating encrypted filesystems (luks cryptsetup style).
my use case: I use virt-builder to create Fedora installs on USB sticks (which is very convenient and fast). And for mobile uses it makes sense to have the main filesystem encrypted.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
A new virt-builder option like `--cryptsetup` that would yield the creation of the main filesystem inside a luks cryptsetup formatted and mapped device. The result would be similar to installing via anaconda and selecting the encryption option. As cryptsetup password the root-password could be used.
Virt-builder works by expanding existing templates. It doesn't
create guests from scratch each time. Therefore what's really
being asked for here is support for encrypted templates.
I've changed the summary accordingly.
However unless there's some way to rekey an encrypted filesystem,
and unless it's safe to create multiple copies from a single
encrypted template, I don't know if this is possible.
We think the way to do this safely is:
(1) Run `cryptsetup-reencrypt' to change the volume (master) key in-place.
This will rewrite the whole partition and could potentially be slow.
(2) Run `cryptsetup luksChangeKey' on the first keyslot to replace the
(3) Run `cryptsetup luksKillSlot' on all the other keyslots to make sure
no other passphrases are left around.
(4) Run `cryptsetup luksUUID --uuid=<random UUID>' to generate a new UUID.
(Some of these could be turned into virt-customize operations)
That's just the changes to virt-builder. Someone would also need to
supply LUKS-encrypted templates.
One possibly fatal problem is that compressed templates do not
compress at all. Modifying the template to add encryption is
well outside the scope of virt-builder, since it doesn't make
complex changes to templates as they are transformed into guests.
(In reply to Richard W.M. Jones from comment #3)
> One possibly fatal problem is that compressed templates do not
> compress at all.
> Modifying the template to add encryption is
> well outside the scope of virt-builder, since it doesn't make
> complex changes to templates as they are transformed into guests.
I don't know if this is already too complex - but for a project where
I need to transfer a VM image with encrypted root partition I did it like this:
1. locally create the image with encrypted root partition
2. split that image into 2 parts (i.e. files), i.e. (1) the range from image begin
to root partition begin and (2) the decrypted content of the luks volume
3. Compress the 2 parts and transfer them with the original luks UUID to the target
4. On the target: insert the first part as-is into a new empty image, create a new luks
volume with the original uuid and insert the second part into it
Since this bug was filed, Dan Berrange added support for LUKS-encrypted qcow2.
This allows you to have images which are encrypted at rest, and all the
encryption machinery is hidden in the hypervisor (qemu) so the guest thinks
it has an unencrypted disk. This may be a better way to solve the problem,
although we might still want to add support for LUKS-encrypted qcow2 to virt-builder.
With QEMU's LUKS support virt-builder is no longer a blocker for dealing with this scenario. You can simply use virt-builder as normal, and then run qemu-img convert afterwards to turn it into an encrypted disk. Obviously having it integrated in virt-builder, however, would make the process more efficient as it could create the encrypted disk immediately avoiding the extra data copy.
> Obviously having it integrated in virt-builder, however, would make the process more
> efficient as it could create the encrypted disk immediately avoiding the extra data copy.
Right, that's what I think is best here. However it's a little bit different from
what the RFE proposer wanted so I'll wait to hear back from them.
Well, the LUKS-encrypted qcow2 doesn't help when using virt-builder to provision
a bare-metal system.
For example, in the past, I used virt-builder to provision USB sticks. Often it makes sense
to encrypt such a USB installation (think: sensitive data, in case you loose it etc.).