[libvirt] [PATCH v9 1/4] conf: Introduce TLS options for VxHS block device clients

[John Ferlan]

On 09/27/2017 08:43 AM, Peter Krempa wrote:
> On Tue, Sep 19, 2017 at 21:32:43 -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>
>> ---
>>  src/qemu/libvirtd_qemu.aug         |  4 ++++
>>  src/qemu/qemu.conf                 | 34 ++++++++++++++++++++++++++++++++++
>>  src/qemu/qemu_conf.c               | 16 ++++++++++++++++
>>  src/qemu/qemu_conf.h               |  3 +++
>>  src/qemu/test_libvirtd_qemu.aug.in |  2 ++
>>  5 files changed, 59 insertions(+)
> 
> [...]
> 
>> +# Enable use of TLS encryption for all VxHS network block devices that
>> +# don't specifically disable.
>> +#
>> +# When the VxHS network block device server is set up appropriately,
>> +# x509 certificates are required for authentication between the clients
>> +# (qemu processes) and the remote VxHS server.
>> +#
>> +# It is necessary to setup CA and issue the client certificate before
>> +# enabling this.
>> +#
>> +#vxhs_tls = 1
>> +
>> +
>> +# In order to override the default TLS certificate location for VxHS
>> +# device TCP certificates, supply a valid path to the certificate directory.
> 
> The first part of the sentence does not make much sense.
> 
> In order to override the default TLS certificate location for VxHS
> backed storage, supply a valid path to the certificate directory.
> 

<me> wondering where "device TCP certificates," slipped into the text...
Looks like it was present back in v4 as well...

I'll adjust to use your text

> 
>> +# 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.
> 
> What do you mean by: "UUID that would decrypt it"?
> 
> Rest looks okay, but I need clarification on the above statemet.
> 


The "server key" comes from the default description of "server-key.pem"
and the rest from the description of default_tls_x509_secret_uuid which
essentially states the UUID would be UUID of a secret that would decrypt
the server-key.pem file.

Basically, it's a way to point out that the VxHS TLS certificate
environment wouldn't use a similar setup from a default (or Chardev or
Migrate) to provide a secret UUID parameter since the configuration is
client only.  I can strike out that last sentence completely as it
perhaps not that important and probably confusing.


John