Bug 1731898 - RFE: support for LUKS key management in qemu-img & QMP
Summary: RFE: support for LUKS key management in qemu-img & QMP
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: qemu-kvm
Version: 8.0
Hardware: All
OS: All
medium
medium
Target Milestone: rc
: 8.0
Assignee: Maxim Levitsky
QA Contact: Tingting Mao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-22 10:56 UTC by Daniel Berrangé
Modified: 2019-07-26 11:29 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Feature Request


Attachments (Terms of Use)

Description Daniel Berrangé 2019-07-22 10:56:29 UTC
Description of problem:
The LUKS encryption format supports multiple key slots. This allows multiple distinct passphrases to be used to unlock the same master encryption key. It also allows for replacement of the passphrases, by adding a new one then removing the old one. This is supported in the 'cryptsetup' tool via several key management commands.

When QEMU is being used with a raw LUKS volume, admins can still use the cryptsetup tool to do key management, however, when LUKS is used in qcow2 this is not practical, because the LUKS header will not be in the place that cryptsetup is expecting.

There is thus a need to support key management in the qemu-img command. We need two commands

 - crypto-add-key
   
   Needs to take an image file path, a key slot number, and the ID of a secret object providing the new passphrase.
   Key slot could be made optional to let us pick a free slot

 - crypto-remove-key

   Needs to take an image file path, and either a key slot number, or the ID of a secret object providing the new passphrase.

   If given a key slot, remove that exact slot
   If given a passphrase, try to unlock each key slot until one succeeds, then remove that one.

   We MUST NOT allow the last key slot to be removed, without explicit confirmation in some way. Perhaps --force option

It is unsafe to use qemu-img on an image used by a running guest, so we also likely need to have QMP + HMP commands which expose the exact same functionality as qemu-img for key slot mgmt.


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