Merge "doc: Document TLS security setup for noVNC proxy"
This commit is contained in:
commit
4e3b07430d
|
@ -9,7 +9,7 @@ command line. Best practice is to select only one of them to run.
|
||||||
.. _about-nova-consoleauth:
|
.. _about-nova-consoleauth:
|
||||||
|
|
||||||
About nova-consoleauth
|
About nova-consoleauth
|
||||||
~~~~~~~~~~~~~~~~~~~~~~
|
----------------------
|
||||||
|
|
||||||
The client proxies leverage a shared service to manage token authentication
|
The client proxies leverage a shared service to manage token authentication
|
||||||
called ``nova-consoleauth``. This service must be running for either proxy to
|
called ``nova-consoleauth``. This service must be running for either proxy to
|
||||||
|
@ -21,7 +21,7 @@ which is a XenAPI-specific service that most recent VNC proxy architectures do
|
||||||
not use.
|
not use.
|
||||||
|
|
||||||
SPICE console
|
SPICE console
|
||||||
~~~~~~~~~~~~~
|
-------------
|
||||||
|
|
||||||
OpenStack Compute supports VNC consoles to guests. The VNC protocol is fairly
|
OpenStack Compute supports VNC consoles to guests. The VNC protocol is fairly
|
||||||
limited, lacking support for multiple monitors, bi-directional audio, reliable
|
limited, lacking support for multiple monitors, bi-directional audio, reliable
|
||||||
|
@ -57,7 +57,7 @@ Replace ``IP_ADDRESS`` with the management interface IP address of the
|
||||||
controller or the VIP.
|
controller or the VIP.
|
||||||
|
|
||||||
VNC console proxy
|
VNC console proxy
|
||||||
~~~~~~~~~~~~~~~~~
|
-----------------
|
||||||
|
|
||||||
The VNC proxy is an OpenStack component that enables compute service users to
|
The VNC proxy is an OpenStack component that enables compute service users to
|
||||||
access their instances through VNC clients.
|
access their instances through VNC clients.
|
||||||
|
@ -72,8 +72,7 @@ The VNC console connection works as follows:
|
||||||
#. A user connects to the API and gets an ``access_url`` such as,
|
#. A user connects to the API and gets an ``access_url`` such as,
|
||||||
``http://ip:port/?token=xyz``.
|
``http://ip:port/?token=xyz``.
|
||||||
|
|
||||||
#. The user pastes the URL in a browser or uses it as a client
|
#. The user pastes the URL in a browser or uses it as a client parameter.
|
||||||
parameter.
|
|
||||||
|
|
||||||
#. The browser or client connects to the proxy.
|
#. The browser or client connects to the proxy.
|
||||||
|
|
||||||
|
@ -104,8 +103,137 @@ client can talk to VNC servers. In general, the VNC proxy:
|
||||||
:alt: noVNC process
|
:alt: noVNC process
|
||||||
:width: 95%
|
:width: 95%
|
||||||
|
|
||||||
|
VNC proxy security
|
||||||
|
~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Deploy the public-facing interface of the VNC proxy with HTTPS to prevent
|
||||||
|
attacks from malicious parties on the network between the tenant user and proxy
|
||||||
|
server. When using HTTPS, the TLS encryption only applies to data between the
|
||||||
|
tenant user and proxy server. The data between the proxy server and Compute
|
||||||
|
node instance will still be unencrypted. To provide protection for the latter,
|
||||||
|
it is necessary to enable the VeNCrypt authentication scheme for VNC in both
|
||||||
|
the Compute nodes and noVNC proxy server hosts.
|
||||||
|
|
||||||
|
QEMU/KVM Compute node configuration
|
||||||
|
+++++++++++++++++++++++++++++++++++
|
||||||
|
|
||||||
|
Ensure each Compute node running QEMU/KVM with libvirt has a set of
|
||||||
|
certificates issued to it. The following is a list of the required
|
||||||
|
certificates:
|
||||||
|
|
||||||
|
- :file:`/etc/pki/libvirt-vnc/server-cert.pem`
|
||||||
|
|
||||||
|
An x509 certificate to be presented **by the VNC server**. The ``CommonName``
|
||||||
|
should match the **primary hostname of the compute node**. Use of
|
||||||
|
``subjectAltName`` is also permitted if there is a need to use multiple
|
||||||
|
hostnames or IP addresses to access the same Compute node.
|
||||||
|
|
||||||
|
- :file:`/etc/pki/libvirt-vnc/server-key.pem`
|
||||||
|
|
||||||
|
The private key used to generate the ``server-cert.pem`` file.
|
||||||
|
|
||||||
|
- :file:`/etc/pki/libvirt-vnc/ca-cert.pem`
|
||||||
|
|
||||||
|
The authority certificate used to sign ``server-cert.pem`` and sign the VNC
|
||||||
|
proxy server certificates.
|
||||||
|
|
||||||
|
The certificates must have v3 basic constraints [3]_ present to indicate the
|
||||||
|
permitted key use and purpose data.
|
||||||
|
|
||||||
|
We recommend using a dedicated certificate authority solely for the VNC
|
||||||
|
service. This authority may be a child of the master certificate authority used
|
||||||
|
for the OpenStack deployment. This is because libvirt does not currently have
|
||||||
|
a mechanism to restrict what certificates can be presented by the proxy server.
|
||||||
|
|
||||||
|
For further details on certificate creation, consult the QEMU manual page
|
||||||
|
documentation on VNC server certificate setup [2]_.
|
||||||
|
|
||||||
|
Configure libvirt to enable the VeNCrypt authentication scheme for the VNC
|
||||||
|
server. In :file:`/etc/libvirt/qemu.conf`, uncomment the following settings:
|
||||||
|
|
||||||
|
- ``vnc_tls=1``
|
||||||
|
|
||||||
|
This instructs libvirt to enable the VeNCrypt authentication scheme when
|
||||||
|
launching QEMU, passing it the certificates shown above.
|
||||||
|
|
||||||
|
- ``vnc_tls_x509_verify=1``
|
||||||
|
|
||||||
|
This instructs QEMU to require that all VNC clients present a valid x509
|
||||||
|
certificate. Assuming a dedicated certificate authority is used for the VNC
|
||||||
|
service, this ensures that only approved VNC proxy servers can connect to the
|
||||||
|
Compute nodes.
|
||||||
|
|
||||||
|
After editing :file:`qemu.conf`, the ``libvirtd`` service must be restarted:
|
||||||
|
|
||||||
|
.. code:: shell
|
||||||
|
|
||||||
|
$ systemctl restart libvirtd.service
|
||||||
|
|
||||||
|
Changes will not apply to any existing running guests on the Compute node, so
|
||||||
|
this configuration should be done before launching any instances.
|
||||||
|
|
||||||
|
noVNC proxy server configuration
|
||||||
|
++++++++++++++++++++++++++++++++
|
||||||
|
|
||||||
|
The noVNC proxy server initially only supports the ``none`` authentication
|
||||||
|
scheme, which does no checking. Therefore, it is necessary to enable the
|
||||||
|
``vencrypt`` authentication scheme by editing the :file:`nova.conf` file to
|
||||||
|
set.
|
||||||
|
|
||||||
|
.. code::
|
||||||
|
|
||||||
|
[vnc]
|
||||||
|
auth_schemes=vencrypt,none
|
||||||
|
|
||||||
|
The :oslo.config:option:`vnc.auth_schemes` values should be listed in order
|
||||||
|
of preference. If enabling VeNCrypt on an existing deployment which already has
|
||||||
|
instances running, the noVNC proxy server must initially be allowed to use
|
||||||
|
``vencrypt`` and ``none``. Once it is confirmed that all Compute nodes have
|
||||||
|
VeNCrypt enabled for VNC, it is possible to remove the ``none`` option from the
|
||||||
|
list of the :oslo.config:option:`vnc.auth_schemes` values.
|
||||||
|
|
||||||
|
At that point, the noVNC proxy will refuse to connect to any Compute node that
|
||||||
|
does not offer VeNCrypt.
|
||||||
|
|
||||||
|
As well as enabling the authentication scheme, it is necessary to provide
|
||||||
|
certificates to the noVNC proxy.
|
||||||
|
|
||||||
|
- :file:`/etc/pki/nova-novncproxy/client-cert.pem`
|
||||||
|
|
||||||
|
An x509 certificate to be presented **to the VNC server**. While libvirt/QEMU
|
||||||
|
will not currently do any validation of the ``CommonName`` field, future
|
||||||
|
versions will allow for setting up access controls based on the
|
||||||
|
``CommonName``. The ``CommonName`` field should match the **primary hostname
|
||||||
|
of the controller node**. If using a HA deployment, the ``Organization``
|
||||||
|
field can also be configured to a value that is common across all console
|
||||||
|
proxy instances in the deployment. This avoids the need to modify each
|
||||||
|
compute node's whitelist every time a console proxy instance is added or
|
||||||
|
removed.
|
||||||
|
|
||||||
|
- :file:`/etc/pki/nova-novncproxy/client-key.pem`
|
||||||
|
|
||||||
|
The private key used to generate the ``client-cert.pem`` file.
|
||||||
|
|
||||||
|
- :file:`/etc/pki/nova-novncproxy/ca-cert.pem`
|
||||||
|
|
||||||
|
The certificate authority cert used to sign ``client-cert.pem`` and sign the
|
||||||
|
compute node VNC server certificates.
|
||||||
|
|
||||||
|
The certificates must have v3 basic constraints [3]_ present to indicate the
|
||||||
|
permitted key use and purpose data.
|
||||||
|
|
||||||
|
Once the certificates have been created, the noVNC console proxy service must
|
||||||
|
be told where to find them. This requires editing :file:`nova.conf` to set.
|
||||||
|
|
||||||
|
.. code::
|
||||||
|
|
||||||
|
[vnc]
|
||||||
|
vencrypt_client_key=/etc/pki/nova-novncproxy/client-key.pem
|
||||||
|
vencrypt_client_cert=/etc/pki/nova-novncproxy/client-cert.pem
|
||||||
|
vencrypt_ca_certs=/etc/pki/nova-novncproxy/ca-cert.pem
|
||||||
|
|
||||||
VNC configuration options
|
VNC configuration options
|
||||||
-------------------------
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
To customize the VNC console, use the following configuration options in your
|
To customize the VNC console, use the following configuration options in your
|
||||||
``nova.conf`` file:
|
``nova.conf`` file:
|
||||||
|
@ -177,7 +305,7 @@ To customize the VNC console, use the following configuration options in your
|
||||||
same network as the proxies.
|
same network as the proxies.
|
||||||
|
|
||||||
Typical deployment
|
Typical deployment
|
||||||
------------------
|
~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
A typical deployment has the following components:
|
A typical deployment has the following components:
|
||||||
|
|
||||||
|
@ -197,7 +325,7 @@ A typical deployment has the following components:
|
||||||
options, as follows.
|
options, as follows.
|
||||||
|
|
||||||
nova-novncproxy (noVNC)
|
nova-novncproxy (noVNC)
|
||||||
-----------------------
|
~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
You must install the noVNC package, which contains the ``nova-novncproxy``
|
You must install the noVNC package, which contains the ``nova-novncproxy``
|
||||||
service. As root, run the following command:
|
service. As root, run the following command:
|
||||||
|
@ -242,7 +370,7 @@ configuration options to your ``nova.conf`` file:
|
||||||
connecting to instance ``vncservers``.
|
connecting to instance ``vncservers``.
|
||||||
|
|
||||||
Frequently asked questions about VNC access to virtual machines
|
Frequently asked questions about VNC access to virtual machines
|
||||||
---------------------------------------------------------------
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
- **Q: What is the difference between ``nova-xvpvncproxy`` and
|
- **Q: What is the difference between ``nova-xvpvncproxy`` and
|
||||||
``nova-novncproxy``?**
|
``nova-novncproxy``?**
|
||||||
|
@ -325,7 +453,7 @@ Frequently asked questions about VNC access to virtual machines
|
||||||
set explicitly where the ``nova-novncproxy`` service is running.
|
set explicitly where the ``nova-novncproxy`` service is running.
|
||||||
|
|
||||||
Serial Console
|
Serial Console
|
||||||
~~~~~~~~~~~~~~
|
--------------
|
||||||
|
|
||||||
The *serial console* feature [1]_ in nova is an alternative for graphical
|
The *serial console* feature [1]_ in nova is an alternative for graphical
|
||||||
consoles like *VNC*, *SPICE*, *RDP*. The example below uses these nodes:
|
consoles like *VNC*, *SPICE*, *RDP*. The example below uses these nodes:
|
||||||
|
@ -366,6 +494,8 @@ Keep these things in mind:
|
||||||
proxying the console interaction.
|
proxying the console interaction.
|
||||||
|
|
||||||
References
|
References
|
||||||
~~~~~~~~~~
|
----------
|
||||||
|
|
||||||
.. [1] https://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/serial-ports.html
|
.. [1] https://specs.openstack.org/openstack/nova-specs/specs/juno/implemented/serial-ports.html
|
||||||
|
.. [2] https://qemu.weilnetz.de/doc/qemu-doc.html#vnc_005fsec_005fcertificate_005fverify
|
||||||
|
.. [3] https://tools.ietf.org/html/rfc3280#section-4.2.1.10
|
||||||
|
|
|
@ -9,6 +9,10 @@ features:
|
||||||
- ``vencrypt_client_key``
|
- ``vencrypt_client_key``
|
||||||
- ``vencrypt_client_cert``
|
- ``vencrypt_client_cert``
|
||||||
- ``vencrypt_ca_certs``
|
- ``vencrypt_ca_certs``
|
||||||
|
|
||||||
|
For more information, refer to `the documentation`__.
|
||||||
|
|
||||||
|
__ https://docs.openstack.org/nova/latest/admin/remote-console-access.html
|
||||||
- |
|
- |
|
||||||
The *nova-novncproxy* server can now be configured to do a security
|
The *nova-novncproxy* server can now be configured to do a security
|
||||||
negotiation with the compute node VNC server. If the VeNCrypt auth scheme
|
negotiation with the compute node VNC server. If the VeNCrypt auth scheme
|
||||||
|
@ -31,3 +35,7 @@ features:
|
||||||
|
|
||||||
Once all compute nodes have VeNCrypt enabled, the ``auth_schemes``
|
Once all compute nodes have VeNCrypt enabled, the ``auth_schemes``
|
||||||
parameter can be set to just ``['vencrypt']``.
|
parameter can be set to just ``['vencrypt']``.
|
||||||
|
|
||||||
|
For more information, refer to `the documentation`__.
|
||||||
|
|
||||||
|
__ https://docs.openstack.org/nova/latest/admin/remote-console-access.html
|
||||||
|
|
Loading…
Reference in New Issue