[libvirt] [PATCH v6 07/13] conf: Introduce TLS options for VxHS block device clients

Peter Krempa pkrempa at redhat.com
Thu Aug 31 12:21:40 UTC 2017


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170831/e1d59b76/attachment-0001.sig>


More information about the libvir-list mailing list