On Wed, Aug 30, 2017 at 18:46:07 -0400, John Ferlan wrote:
From: Ashish Mittal <Ashish.Mittal(a)veritas.com>
Add a new TLS X.509 certificate type - "vxhs". This will handle the
creation of a TLS certificate capability for properly configured
VxHS network block device clients.
The following describes the behavior of TLS for VxHS block device:
(1) Two new options have been added in /etc/libvirt/qemu.conf
to control TLS behavior with VxHS block devices
"vxhs_tls" and "vxhs_tls_x509_cert_dir".
(2) Setting "vxhs_tls=1" in /etc/libvirt/qemu.conf will enable
TLS for VxHS block devices.
(3) "vxhs_tls_x509_cert_dir" can be set to the full path where the
TLS CA certificate and the client certificate and keys are saved.
If this value is missing, the "default_tls_x509_cert_dir" will be
used instead. If the environment is not configured properly the
authentication to the VxHS server will fail.
Signed-off-by: Ashish Mittal <Ashish.Mittal(a)veritas.com>
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
This is "most of" the v5 patch4 with a few adjustments:
* Alter the qemu.conf description to describe what files are really
necessary for the environment, especially if someone was going to
assume the default environment would work.
* Extracted the formatdomain.html.in and moved it to the subsequent
patch where the domain XML is updated
* Added calls/checks to CHECK_RESET_CERT_DIR_DEFAULT(vxhs); and
virQEMUDriverConfigValidate. I think we could possibly add more
to the validate check to ensure the "right" files are there -
especially the client files, but I wasn't sure if we should or
not so left it as an exercise for later
src/qemu/libvirtd_qemu.aug | 4 ++++
src/qemu/qemu.conf | 33 +++++++++++++++++++++++++++++++++
src/qemu/qemu_conf.c | 16 ++++++++++++++++
src/qemu/qemu_conf.h | 3 +++
src/qemu/test_libvirtd_qemu.aug.in | 2 ++
5 files changed, 58 insertions(+)
[...]
diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
index f977e3b..f92d5fe 100644
--- a/src/qemu/qemu.conf
+++ b/src/qemu/qemu.conf
@@ -258,6 +258,39 @@
#chardev_tls_x509_secret_uuid = "00000000-0000-0000-0000-000000000000"
+# Enable use of TLS encryption on the VxHS network block devices.
+#
+# When the VxHS network block device server is set up appropriately,
+# x509 certificates are used for authentication between the clients
+# (qemu processes) and the remote VxHS server.
+#
+# It is necessary to setup CA and issue client and server certificates
+# before enabling this.
+#
+#vxhs_tls = 1
I find the semantics of this parameter weird since it does two things at
the same time:
1) it says that you CAN use TLS for vhxs
(if it's not set and you set tls='yes' in the XML you get an error)
2) It changes the default from tls='no' to tls='yes', if it was not
specified.
This means that there's no way to 'opt-in' to use TLS. I don't quite see
why the first thing is necessary at all. If you set the cert dir below
and the certificates exist I don't see why users should be forced to
switch the default to be able to use TLS.
+# In order to override the default TLS certificate location for
VxHS
+# device TCP certificates, supply a valid path to the certificate directory.
+# This is used to authenticate the VxHS block device clients to the VxHS
+# server.
+#
+# If the provided path does not exist then the default_tls_x509_cert_dir
+# path will be used.
+#
+# VxHS block device clients expect the client certificate and key to be
+# present in the certificate directory along with the CA master certificate.
+# If using the default environment, default_tls_x509_verify must be configured.
+# The server key as well as secret UUID that would decrypt it is not used.
+# Thus a VxHS directory must contain the following:
+#
+# ca-cert.pem - the CA master certificate
+# client-cert.pem - the client certificate signed with the ca-cert.pem
+# client-key.pem - the client private key
+#
+#vxhs_tls_x509_cert_dir = "/etc/pki/libvirt-vxhs"