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>
---
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(+)
diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
index e1983d1fd..c19bf3a43 100644
--- a/src/qemu/libvirtd_qemu.aug
+++ b/src/qemu/libvirtd_qemu.aug
@@ -115,6 +115,9 @@ module Libvirtd_qemu =
let memory_entry = str_entry "memory_backing_dir"
+ let vxhs_entry = bool_entry "vxhs_tls"
+ | str_entry "vxhs_tls_x509_cert_dir"
+
(* Each entry in the config is one of the following ... *)
let entry = default_tls_entry
| vnc_entry
@@ -133,6 +136,7 @@ module Libvirtd_qemu =
| nvram_entry
| gluster_debug_level_entry
| memory_entry
+ | vxhs_entry
let comment = [ label "#comment" . del /#[ \t]*/ "# " . store /([^ \t\n][^\n]*)?/ . del /\n/ "\n" ]
let empty = [ label "#empty" . eol ]
diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
index f977e3b71..2d20d790b 100644
--- a/src/qemu/qemu.conf
+++ b/src/qemu/qemu.conf
@@ -258,6 +258,40 @@
#chardev_tls_x509_secret_uuid = "00000000-0000-0000-0000-000000000000"
+# 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.
+# 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"
+
+
# In order to override the default TLS certificate location for migration
# certificates, supply a valid path to the certificate directory. If the
# provided path does not exist then the default_tls_x509_cert_dir path
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 68c00c1e8..ec61c9c52 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -283,6 +283,7 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool privileged)
SET_TLS_X509_CERT_DEFAULT(spice);
SET_TLS_X509_CERT_DEFAULT(chardev);
SET_TLS_X509_CERT_DEFAULT(migrate);
+ SET_TLS_X509_CERT_DEFAULT(vxhs);
#undef SET_TLS_X509_CERT_DEFAULT
@@ -380,6 +381,8 @@ static void virQEMUDriverConfigDispose(void *obj)
VIR_FREE(cfg->chardevTLSx509certdir);
VIR_FREE(cfg->chardevTLSx509secretUUID);
+ VIR_FREE(cfg->vxhsTLSx509certdir);
+
VIR_FREE(cfg->migrateTLSx509certdir);
VIR_FREE(cfg->migrateTLSx509secretUUID);
@@ -457,6 +460,7 @@ virQEMUDriverConfigTLSDirResetDefaults(virQEMUDriverConfigPtr cfg)
CHECK_RESET_CERT_DIR_DEFAULT(spice);
CHECK_RESET_CERT_DIR_DEFAULT(chardev);
CHECK_RESET_CERT_DIR_DEFAULT(migrate);
+ CHECK_RESET_CERT_DIR_DEFAULT(vxhs);
return 0;
}
@@ -556,6 +560,10 @@ int virQEMUDriverConfigLoadFile(virQEMUDriverConfigPtr cfg,
goto cleanup;
if (virConfGetValueBool(conf, "spice_auto_unix_socket", &cfg->spiceAutoUnixSocket) < 0)
goto cleanup;
+ if (virConfGetValueBool(conf, "vxhs_tls", &cfg->vxhsTLS) < 0)
+ goto cleanup;
+ if (virConfGetValueString(conf, "vxhs_tls_x509_cert_dir", &cfg->vxhsTLSx509certdir) < 0)
+ goto cleanup;
#define GET_CONFIG_TLS_CERTINFO(val) \
do { \
@@ -976,6 +984,14 @@ virQEMUDriverConfigValidate(virQEMUDriverConfigPtr cfg)
return -1;
}
+ if (STRNEQ(cfg->vxhsTLSx509certdir, SYSCONFDIR "/pki/qemu") &&
+ !virFileExists(cfg->vxhsTLSx509certdir)) {
+ virReportError(VIR_ERR_CONF_SYNTAX,
+ _("vxhs_tls_x509_cert_dir directory '%s' does not exist"),
+ cfg->vxhsTLSx509certdir);
+ return -1;
+ }
+
return 0;
}
diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h
index d469b50bd..13b6f818a 100644
--- a/src/qemu/qemu_conf.h
+++ b/src/qemu/qemu_conf.h
@@ -203,6 +203,9 @@ struct _virQEMUDriverConfig {
unsigned int glusterDebugLevel;
char *memoryBackingDir;
+
+ bool vxhsTLS;
+ char *vxhsTLSx509certdir;
};
/* Main driver state */
diff --git a/src/qemu/test_libvirtd_qemu.aug.in b/src/qemu/test_libvirtd_qemu.aug.in
index 676d48cf5..688e5b9fd 100644
--- a/src/qemu/test_libvirtd_qemu.aug.in
+++ b/src/qemu/test_libvirtd_qemu.aug.in
@@ -25,6 +25,8 @@ module Test_libvirtd_qemu =
{ "chardev_tls_x509_cert_dir" = "/etc/pki/libvirt-chardev" }
{ "chardev_tls_x509_verify" = "1" }
{ "chardev_tls_x509_secret_uuid" = "00000000-0000-0000-0000-000000000000" }
+{ "vxhs_tls" = "1" }
+{ "vxhs_tls_x509_cert_dir" = "/etc/pki/libvirt-vxhs" }
{ "migrate_tls_x509_cert_dir" = "/etc/pki/libvirt-migrate" }
{ "migrate_tls_x509_verify" = "1" }
{ "migrate_tls_x509_secret_uuid" = "00000000-0000-0000-0000-000000000000" }
--
2.13.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Sep 19, 2017 at 21:32:43 -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> > --- > 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. > +# 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. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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@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> >> --- >> 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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Sep 27, 2017 at 09:12:06 -0400, John Ferlan wrote: > > > 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@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> > >> --- > >> 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(+) [...] > 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. Ah, right. > > 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. You can state that since this is only a client, the server key/cert is not needed in such configuration, which automatically implies that the secret for decrypting it is not necessary as well. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Sep 27, 2017 at 15:27:15 +0200, Peter Krempa wrote: > On Wed, Sep 27, 2017 at 09:12:06 -0400, John Ferlan wrote: > > > > > > 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@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> > > >> --- > > >> 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(+) > > [...] > > > 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. > > Ah, right. > > > > > 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. > > You can state that since this is only a client, the server key/cert is > not needed in such configuration, which automatically implies that the > secret for decrypting it is not necessary as well. ACK with the above modification. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2026 Red Hat, Inc.