Open Stack

On 24 January 2018 at 22:57, Matt Riedemann <mriedemos at gmail.com> wrote:

> On 1/22/2018 8:22 AM, Lee Yarwood wrote:
>
>> Hello,
>>
>> With M3 and FF rapidly approaching this week I wanted to post a brief
>> overview of the QEMU native LUKS series.
>>
>> The full series is available on the following topic, I'll go into more
>> detail on each of the changes below:
>>
>> https://review.openstack.org/#/q/topic:bp/libvirt-qemu-nativ
>> e-luks+status:open
>>
>> libvirt: Collocate encryptor and volume driver calls
>> https://review.openstack.org/#/c/460243/ (Missing final +2 and +W)
>>
>> This refactor of the Libvirt driver connect and disconnect volume code
>> has the added benefit of also correcting a number of bugs around the
>> attaching and detaching of os-brick encryptors. IMHO this would be
>> useful in Queens even if the rest of the series doesn't land.
>>
>> libvirt: Introduce disk encryption config classes
>> https://review.openstack.org/#/c/464008/ (Missing final +2 and +W)
>>
>> This is the most straight forward change of the series and simply
>> introduces the required config classes to wire up native LUKS decryption
>> within the domain XML of an instance. Hopefully nothing controversial.
>>
>> libvirt: QEMU native LUKS decryption for encrypted volumes
>> https://review.openstack.org/#/c/523958/ (Missing both +2s and +W)
>>
>> This change carries the bulk of the implementation, wiring up encrypted
>> volumes during their initial attachment. The commit message has a
>> detailed run down of the various upgrade and LM corner cases we attempt
>> to handle here, such as LM from a P to Q compute, detaching a P attached
>> encrypted volume after upgrading to Q etc.
>>
>> Upgrade and LM testing is enabled by the following changes:
>>
>> fixed_key: Use a single hardcoded key across devstack deployments
>> https://review.openstack.org/#/c/536343/
>>
>> compute: Introduce an encrypted volume LM test
>> https://review.openstack.org/#/c/536177/
>>
>> This is being tested by tempest-dsvm-multinode-live-migration and
>> grenade-dsvm-neutron-multinode-live-migration in the following DNM Nova
>> change, enabling volume backed LM tests:
>>
>> DNM: Test LM with encrypted volumes
>> https://review.openstack.org/#/c/536350/
>>
>> Hopefully that covers everything but please feel free to ping if you
>> would like more detail, background etc. Thanks in advance,
>>
>> Lee
>>
>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> The patch is already approved, and I asked melwitt to write a release
> note, at which point it was noted that swap volume will not work with
> native luks encrypted volumes. That's a regression.
>

It's only a regression since swap_volume with encrypted volumes was fixed
in https://review.openstack.org/#/c/460243/, which landed on Monday as part
of this series. Prior to Monday, swap_volume with encrypted volumes would
result in the raw encrypted volume being presented to the guest after the
swap.

We need to at least report a nova bug for this so we can work on some kind
> of fallback to the non-native decryption until there is a libvirt/qemu fix
> upstream and we can put version conditionals in place for when we can
> support swap volume with a native luks-encrypted volume.
>

In the context of the above, I don't think this is a priority as clearly
nobody is currently doing it. There's already a bug to track the problem in
libvirt, which is linked in a code comment. Admittedly that BZ is
unnecessarily private, which I noted in review, but we've reached out to
the author to ask them to open it up as there's nothing sensitive going on
in there.

In general, anything qemu can do natively makes Nova both simpler and more
robust because we don't have to modify the host configuration. This
eliminates a whole class of error states and race conditions, because when
we kill qemu there's nothing left to clean up.

Matt
-- 
Matthew Booth
Red Hat OpenStack Engineer, Compute DFG

Phone: +442070094448 (UK)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180125/c22e740f/attachment.html>