[libvirt] [PATCH v5 6/6] qemu: Utilize qemu secret objects for RBD auth/secret

[Peter Krempa]

On Thu, May 19, 2016 at 16:29:05 -0400, John Ferlan wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1182074
> 
> If they're available and we need to pass secrets to qemu, then use the
> qemu domain secret object in order to pass the secrets for RBD volumes
> instead of passing the base64 encoded secret on the command line.
> 
> The goal is to make AES secrets the default and have no user interaction
> required in order to allow using the AES mechanism. If the mechanism
> is not available, then fall back to the current plain mechanism using
> a base64 encoded secret.
> 
> New APIs:
> 
> qemu_domain.c:
>   qemuDomainGetSecretAESAlias:
>     Generate/return the secret object alias for an AES Secret Info type.
>     This will be called from qemuDomainSecretAESSetup.
> 
>   qemuDomainSecretAESSetup: (private)
>     This API handles the details of the generation of the AES secret
>     and saves the pieces that need to be passed to qemu in order for
>     the secret to be decrypted. The encrypted secret based upon the
>     domain master key, an initialization vector (16 byte random value),
>     and the stored secret. Finally, the requirement from qemu is the IV
>     and encrypted secret are to be base64 encoded.
> 
> qemu_command.c:
>   qemuBuildSecretInfoProps: (private)
>     Generate/return a JSON properties object for the AES secret to
>     be used by both the command building and eventually the hotplug
>     code in order to add the secret object. Code was designed so that
>     in the future perhaps hotplug could use it if it made sense.
> 
>   qemuBuildObjectSecretCommandLine (private)
>     Generate and add to the command line the -object secret for the
>     secret. This will be required for the subsequent RBD reference
>     to the object.
> 
>   qemuBuildDiskSecinfoCommandLine (private)
>     Handle adding the AES secret object.
> 
> Adjustments:
> 
> qemu_domain.c:
>   The qemuDomainSecretSetup was altered to call either the AES or Plain
>   Setup functions based upon whether AES secrets are possible (we have
>   the encryption API) or not, we have secrets, and of course if the
>   protocol source is RBD.
> 
> qemu_command.c:
>   Adjust the qemuBuildRBDSecinfoURI API's in order to generate the
>   specific command options for an AES secret, such as:
> 
>     -object secret,id=$alias,keyid=$masterKey,data=$base64encodedencrypted,
>             format=base64
>     -drive file=rbd:pool/image:id=myname:auth_supported=cephx\;none:\
>            mon_host=mon1.example.org\:6321,password-secret=$alias,...
> 
>   where the 'id=' value is the secret object alias generated by
>   concatenating the disk alias and "-aesKey0". The 'keyid= $masterKey'
>   is the master key shared with qemu, and the -drive syntax will
>   reference that alias as the 'password-secret'. For the -drive
>   syntax, the 'id=myname' is kept to define the username, while the
>   'key=$base64 encoded secret' is removed.
> 
>   While according to the syntax described for qemu commit '60390a21'
>   or as seen in the email archive:
> 
>     https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg04083.html
> 
>   it is possible to pass a plaintext password via a file, the qemu
>   commit 'ac1d8878' describes the more feature rich 'keyid=' option
>   based upon the shared masterKey.
> 
> Add tests for checking/comparing output.
> 
> NB: For hotplug, since the hotplug code doesn't add command line
>     arguments, passing the encoded secret directly to the monitor
>     will suffice.

I didn't read the commit message.

> 
> Signed-off-by: John Ferlan <jferlan at redhat.com>
> ---

ACK
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160520/ebe5f986/attachment-0001.sig>