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@xxxxxxxxxx> > --- ACK
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list