[libvirt] [PATCH v5 6/6] qemu: Utilize qemu secret objects for RBD auth/secret
Peter Krempa
pkrempa at redhat.com
Fri May 20 13:18:40 UTC 2016
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>
More information about the libvir-list
mailing list