Re: [libvirt] [PATCH v2 8/8] qemu: Utilize qemu secret objects for SCSI/RBD auth/secret

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 iSCSI and RBD volumes instead of passing plaintext or base64 encoded secrets on the command line. Adjust the qemuDomainSecretHaveEncrypt API in order to check for the HAVE_GNUTLS_CIPHER_ENCRYPT being set as the primary decision point to whether an IV secret can be attempted and fall back to plain secret if the API is not available. The goal is to make IV secrets the default and have no user interaction required in order to allow using the IV mechanism. If the mechanism is not available, then fall back to the current mechanism. New API's: qemuBuildSecretInfoProps: (private) Generate/return a JSON properties object for the IV 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. qemuBuildSecretIVCommandLine (private) Generate and add to the command line the -object secret for the IV secret. This will be required for the subsequent iSCSI or RBD reference to the object. qemuBuildiSCSICommandLine: (private) Required for iSCSI since qemu only processes the "user=" and "password-secret=" options for an "-iscsi" entry. At some point in a future release, qemu may support those options on the -drive command line for iscsi devices. The one caveat to this code is rather than provide an 'id=' field for the -iscsi command, use the "initiator-name=" argument since it doesn't have the same restrictions regarding characters. The initiator-name is described as taking an IQN, which is the path argument. qemuBuildDiskSecinfoCommandLine qemuBuildHostdevSecretCommandLine These API's will handle adding the IV secret object and if necessary the '-iscsi' command line option. For an RBD disk, only the IV secret object will be required. Command Building: Adjust the qemuBuild{General|RBD}SecinfoURI API's in order to generate the specific command options for an IV secret, such as: For iSCSI: -object secret,id=$alias,keyid=$masterKey,data=$base64encodedencrypted, format=base64 -iscsi -initiator-name=$iqn,user=user,password-secret=$alias -drive file=iscsi://example.com/$iqn,... For RBD: -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 for both 'id=' value is the secret object alias generated by concatenating the disk/hostdev alias and "-ivKey0". The 'keyid= $masterKey' is the master key shared with qemu, and the -drive syntax will reference that alias as the 'password-secret'. For the iSCSI object 'user=' replaces the URI generated 'user:secret@' prepended to the iSCSI 'host' name (example.com). For the RBD -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 commits 'b189346eb' (iSCSI) and '60390a21' (RBD) 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. Tests: Add mock's for virRandomBytes and gnutls_rnd in order to return a constant stream of '0xff' in the bytes for a non random key in order to generate "constant" values for the secrets so that the tests can use those results to compare results. Hotplug: Since the hotplug code doesn't add command line arguments, passing the encoded/plaintext secrets directly to the monitor will suffice. Besides, it's passing the IV secret via '-iscsi' won't be possible. Perhaps when the -drive command is modified to accept not only the initiator-name, but -user and -password-secret arguments, then the IV code can be utilized for hotplug secrets. Signed-off-by: John Ferlan <jferlan(a)redhat.com&gt; --- configure.ac | 1 + src/qemu/qemu_command.c | 257 ++++++++++++++++++++- src/qemu/qemu_domain.c | 4 + ...uxml2argv-disk-drive-network-iscsi-auth-IV.args | 39 ++++ ...muxml2argv-disk-drive-network-iscsi-auth-IV.xml | 43 ++++ ...emuxml2argv-disk-drive-network-rbd-auth-IV.args | 31 +++ ...qemuxml2argv-disk-drive-network-rbd-auth-IV.xml | 42 ++++ ...emuxml2argv-hostdev-scsi-lsi-iscsi-auth-IV.args | 41 ++++ ...qemuxml2argv-hostdev-scsi-lsi-iscsi-auth-IV.xml | 48 ++++ ...xml2argv-hostdev-scsi-virtio-iscsi-auth-IV.args | 43 ++++ ...uxml2argv-hostdev-scsi-virtio-iscsi-auth-IV.xml | 48 ++++ tests/qemuxml2argvmock.c | 31 ++- tests/qemuxml2argvtest.c | 19 ++ 13 files changed, 643 insertions(+), 4 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi-auth-IV.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi-auth-IV.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd-auth-IV.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd-auth-IV.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-lsi-iscsi-auth-IV.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-lsi-iscsi-auth-IV.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-virtio-iscsi-auth-IV.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-virtio-iscsi-auth-IV.xml diff --git a/configure.ac b/configure.ac index 88e2e20..3cabd5e 100644 --- a/configure.ac +++ b/configure.ac @@ -1264,6 +1264,7 @@ if test "x$with_gnutls" != "xno"; then ]]) AC_CHECK_FUNCS([gnutls_rnd]) + AC_CHECK_FUNCS([gnutls_cipher_encrypt])

CFLAGS="$old_CFLAGS" LIBS="$old_LIBS" diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index b56277f..27e31ec 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -607,9 +607,227 @@ qemuNetworkDriveGetPort(int protocol, }