Bug 1400332 - RFE: virt-builder should support templates with encrypted filesystems
Summary: RFE: virt-builder should support templates with encrypted filesystems
Status: NEW
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libguestfs   
(Show other bugs)
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-30 22:46 UTC by Georg Sauthoff
Modified: 2019-01-17 16:02 UTC (History)
2 users (show)

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: ---


Attachments (Terms of Use)

Description Georg Sauthoff 2016-11-30 22:46:55 UTC
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:

Comment 1 Richard W.M. Jones 2016-12-01 09:10:51 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.

Comment 2 Richard W.M. Jones 2016-12-01 10:33:55 UTC
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.

Comment 3 Richard W.M. Jones 2016-12-02 16:26:15 UTC
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.

Comment 4 Georg Sauthoff 2019-01-15 20:28:57 UTC
(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

Comment 5 Richard W.M. Jones 2019-01-16 11:04:29 UTC
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.

Comment 6 Daniel Berrange 2019-01-16 11:18:52 UTC
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.

Comment 7 Richard W.M. Jones 2019-01-16 11:35:12 UTC
> 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.

Comment 8 Georg Sauthoff 2019-01-17 16:02:01 UTC
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.).


Note You need to log in before you can comment on or make changes to this bug.