Bug 1400332
Summary: | RFE: virt-builder should support templates with encrypted filesystems | ||
---|---|---|---|
Product: | [Community] Virtualization Tools | Reporter: | Georg Sauthoff <fedora> |
Component: | libguestfs | Assignee: | Richard W.M. Jones <rjones> |
Status: | NEW --- | QA Contact: | |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | unspecified | CC: | berrange, ptoscano |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | Type: | Bug | |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Georg Sauthoff
2016-11-30 22:46:55 UTC
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. |