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): libguestfs-tools-1.34.3-1.fc25.noarch How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: 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. Additional info:
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 passphrase. (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. Exactly. > 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 cf. https://github.com/gsauthof/dracut-sshd/blob/master/ci/setup/split-img.sh 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 cf. https://github.com/gsauthof/dracut-sshd/blob/master/ci/concat-img.sh
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.).
Just noticed that current LUKS cryptsetup has a new subcommand: reencrypt cf. https://manpath.be/f31/cryptsetup/2.2.2-1.fc31.x86_64/8/cryptsetup#L167 It also supports encrypting a device that already has a filesystem on it, i.e. without destroying it. Thus, when using this mechanism, virt-builder could use an unencrypted template and just call `cryptsetup reencrypt ...` at the end on the root device. virt-builder either needs to adjust the `rd.luks.uuid=` kernel parameter after the reencrypt or call cryptsetup with the UUID (cf. --uuid) that is already contained in the template.