On Wed, Aug 30, 2017 at 18:46:07 -0400, John Ferlan wrote: > From: Ashish Mittal <Ashish Mittal 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 veritas com> > Signed-off-by: John Ferlan <jferlan 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"
Description: PGP signature