Bug 1301026

Summary: [RFE] LUKS encryption of all Nova ephemeral disk backends (local (RAW), QCOW2, rbd and LVM)
Product: Red Hat OpenStack Reporter: Daniel Berrangé <berrange>
Component: openstack-novaAssignee: Lee Yarwood <lyarwood>
Status: ON_DEV --- QA Contact: Joe H. Rahme <jhakimra>
Severity: urgent Docs Contact:
Priority: medium    
Version: 17.0 (Wallaby)CC: alifshit, amodi, brault, dasmith, egallen, eglynn, fduthill, fherrman, gcharot, kchamart, lyarwood, mbooth, sbauza, sgordon, srevivo, stephenfin, vromanso
Target Milestone: ---Keywords: FutureFeature, Patch, Tracking, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 1353247 1821539 (view as bug list) 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: Wallaby
Bug Depends On: 760547, 1301021, 1305024, 1375855, 1518998, 1518999    
Bug Blocks: 1352501, 1476900, 1518616, 1821539, 1230405, 1336045, 1558125    

Description Daniel Berrangé 2016-01-22 11:15:15 UTC
Description of problem:
Nova currently has some limited encryption support which works with LVM volumes. This is not a particularly common deployment choice. The encryption support needs to be extended to cover qcow2 files, RBD and iSCSI volumes at the very minimum. This will require QEMU to have native support for the LUKS encryption format.

Comment 3 Stephen Gordon 2017-03-14 19:47:42 UTC
Kashyap are there other dependencies for this work? The linked dependency is (theoretically) resolved?

Comment 4 Daniel Berrangé 2017-03-14 19:55:30 UTC
Unfortunately the infrastructure isn't fully completed. QEMU has support for LUKS over plain files, block devices and network volumes, but doesn't have LUKS integration into qcow2 yet. Libvirt supports LUKS over plain files and block devices, but not yet for network volumes.

It is enough to start working on the nova piece, but not complete it yet

Comment 5 Kashyap Chamarthy 2017-03-15 11:09:11 UTC
(In reply to Daniel Berrange from comment #4)
> Unfortunately the infrastructure isn't fully completed. QEMU has support for
> LUKS over plain files, block devices and network volumes, but doesn't have
> LUKS integration into qcow2 yet.

Dan, I presume this in-progress upstream QEMU patch series (that adds LUKS support to QCOW2) from you, is what you're referring to (which I've been following from a distance)

https://lists.nongnu.org/archive/html/qemu-devel/2017-02/msg04653.html --
[PATCH v5 00/18] Convert QCow[2] to QCryptoBlock & add LUKS support

> Libvirt supports LUKS over plain files and
> block devices, but not yet for network volumes.
> 
> It is enough to start working on the nova piece, but not complete it yet

Comment 6 Kashyap Chamarthy 2017-08-31 11:17:03 UTC
So, the v10 of the relevant QEMU patch series from DanPB:

    "[PATCH v10 00/20] Convert QCow[2] to QCryptoBlock & add LUKS support"
    -- https://lists.nongnu.org/archive/html/qemu-block/2017-06/msg00755.html) 

is merged in QEMU 2.10 (released on 30-Aug-2017).

Comment 8 Lee Yarwood 2018-02-20 15:33:04 UTC
Moving to rhos-15.0? given RHEL dependencies will not be available during Rocky development.

Comment 9 Kashyap Chamarthy 2019-01-29 10:09:12 UTC
Dan,

Besides the patch series pointed out in comment#6 (which is merged), do
you recall if there is any other pending action on libvirt and QEMU?

From a past conversation with Eric Blake, it looks like the following
two bugs are also relevant here:

    https://bugzilla.redhat.com/show_bug.cgi?id=760547 -- [RFE] 
    specifying the entire image chain as a qemu drive (blockdev-add)

    https://bugzilla.redhat.com/show_bug.cgi?id=1375855 -- LUKS 
    encryption not supported for snapshots' backing files

That was my IRC chat with Eric (from September 2017).  Eric writes:

    You can't create snapshots on top of an encrypted image, unless you  
    can pass the secret to use the encrypted image as a backing file.  
    So libvirt has to use persistent backing chains (rather than
    recomputing it each time the domain supports), if the XML is going
    to track association of a secret with a member of the backing chain.
    That's true whether or not libvirt uses '-blockdev', but switching
    to '-blockdev' is natural fallout from that work.

    QEMU already supports associating a secret with any depth in the 
    backing chain, but that support is easiest when using '-blockdev'.
    (You have to use pseudo-JSON backing file references otherwise,
    which gets hairy).  So there's all the more incentive for libvirt to
    just supply '-blockdev' instructions to QEMU in the first place.

Need to investigate how much of the above is still relevant.  I know 
Peter Krempa has already been working on '-blockdev' support for a
while.

Comment 10 Ademar Reis 2019-04-18 17:15:46 UTC
(In reply to Kashyap Chamarthy from comment #9)
> Dan,
> 
> Besides the patch series pointed out in comment#6 (which is merged), do
> you recall if there is any other pending action on libvirt and QEMU?
> 
> From a past conversation with Eric Blake, it looks like the following
> two bugs are also relevant here:
> 
>     https://bugzilla.redhat.com/show_bug.cgi?id=760547 -- [RFE] 
>     specifying the entire image chain as a qemu drive (blockdev-add)
> 
>     https://bugzilla.redhat.com/show_bug.cgi?id=1375855 -- LUKS 
>     encryption not supported for snapshots' backing files
> 
> That was my IRC chat with Eric (from September 2017).  Eric writes:
> 
>     You can't create snapshots on top of an encrypted image, unless you  
>     can pass the secret to use the encrypted image as a backing file.  
>     So libvirt has to use persistent backing chains (rather than
>     recomputing it each time the domain supports), if the XML is going
>     to track association of a secret with a member of the backing chain.
>     That's true whether or not libvirt uses '-blockdev', but switching
>     to '-blockdev' is natural fallout from that work.
> 
>     QEMU already supports associating a secret with any depth in the 
>     backing chain, but that support is easiest when using '-blockdev'.
>     (You have to use pseudo-JSON backing file references otherwise,
>     which gets hairy).  So there's all the more incentive for libvirt to
>     just supply '-blockdev' instructions to QEMU in the first place.
> 
> Need to investigate how much of the above is still relevant.  I know 
> Peter Krempa has already been working on '-blockdev' support for a
> while.

I'm adding several BZs to the "depends-on" list. The current status is that this feature primarily depends on blockdev work being done in upstream libvirt. Downstream target is RHEL-AV-8.1 (some of the BZs are still marked rhel-7.7, but that's misleading and will be fixed in the next days/weeks).

Comment 11 Lee Yarwood 2019-12-04 14:11:25 UTC
*** Bug 1631239 has been marked as a duplicate of this bug. ***