1. Introduction

The following document describe a feature that allows securing the console access through CloudStack to the virtual machines running on KVM. The secure access is achieved through the generated certificates for the CA Framework in CloudStack, that provides mutual TLS connections between agents. These certificates are used to also secure the connection between the console proxies and the VNC ports for VM console access.

This feature is only supported on the KVM hypervisor

1.1. QEMU/libvirt configuration for VNC encryption

QEMU provides a mechanism to secure the VNC traffic for the virtual machines console access, through certificate authority and server certificates. CloudStack already supports the Certificate Authority method on the KVM, CPVM and SSVM agents. To configure the VNC connections for TLS using the existing certificates it is needed to copy the CA certificate, server certificate and private key for the server certificate to a location in the filesystem but with a special naming. In this example, we are assuming that the certificates are copied into the ‘/etc/pki/libvirt-vnc’ directory on each KVM host:

  • Name the CA Certificate as ‘ca-cert.pem’ under the directory
  • Name the Server Certificate as ‘server-cert.pem’ under the directory
  • Name the Server Certificate Private Key file as ‘server-key.pem’ under the directory

After setting up the certificates, the administrator needs to modify the /etc/libvirt/qemu.conf file:

  • The selected certificates directory needs to be specified on the property ‘vnc_tls_x509_verify_dir’
  • The property ‘vnc_tls’ indicates whether TLS is enabled or disabled (values: 0/1). This property is disabled by default, and was the only supported value on the previous CloudStack versions. To enable TLS connections, set this value to 1
  • To enable the certificates verification for the clients connecting to the VNC ports, the property ‘vnc_tls_x509_verify’ must be set to 1. This value is disabled by default

The administrator must ensure the qemu process can access the certificates directory, providing the necessary privileges (if needed). After that, the last step of the configuration is a restart of the libvirt daemon service.

The complete guide can be found on: https://wiki.libvirt.org/page/VNCTLSSetup 

1.2. VEncrypt Security types and RFB protocol extension

The RFB protocol (https://www.rfc-editor.org/rfc/rfc6143.html) is the protocol used to establish VNC communications, allowing to connect remotely to virtual machines consoles. The implementation of this feature required the upgrade of the supported RFB protocol on the console proxy VMs from version 3.3 to 3.8.

Prior to this feature, the CloudStack console proxies supported the version 3.3 of the RFB protocol. The version 3.3 does not provide any encrypted security type. The only security type provided by the version 3.3 is the VM password authentication. By enabling the TLS on the VNC traffic through QEMU, then the security type provided by the VNC ports included a security type called VEncrypt (https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#724vencrypt). VEncrypt as a security type provides multiple security types:

256PlainPlain authentication
257TLSNoneTLS encryption with no authentication
258TLSVncTLS encryption with VNC authentication
259TLSPlainTLS encryption with Plain authentication
260X509NoneX509 encryption with no authentication
261X509VncX509 encryption with VNC authentication
262X509PlainX509 encryption with Plain authentication
263TLSSASLTLS encryption with SASL authentication
264X509SASLX509 encryption with SASL authentication

The security type offered by QEMU when enabling TLS and the X509 verification is the type 261: X509 encryption with VM password authentication

2. CloudStack Automatic VNC encryption on KVM

This feature work along with the CA Framework in CloudStack. The QEMU/libvirt configuration is automatically triggered on the KVM hosts when the hosts are secured with the CA Framework certificates:

  • The provisionCertificate API is extended, to enable TLS on VNC
  • When a new host is added and it is provisioned with a certificate, TLS will also be enabled for VNC
  • After provisionCertificate API execution, a host is secured with VNC encryption as described in section 1.1
  • The running VMs on a secured host will continue to be VNC unencrypted unless they are rebooted, or stopped and started.
  • New VMs created on a secured host will be VNC encrypted

3. CloudStack Access to VNC encrypted VMs

Once the administrator concludes certificates provisioning on Cloudstack, the VM console access for new VMs on the hosts will be encrypted. CloudStack displays the console of the virtual machines though the noVNC viewer embedded on the console proxy VMs.

The CloudStack users will notice the encrypted VNC sessions display a green bar stating the session is encrypted as in the image below. Also, the tab title includes ‘(TLS backend)’ when the session is encrypted.

4. References

  • No labels