[Openstack-operators] Console security question when using nova-novncproxy to access console

Niall Power niall.power at oracle.com
Wed Oct 22 03:30:31 UTC 2014

Hi all,

I have a question about a security consideration on a compute node when 
using nova-novncproxy for console access.

Is there any existing mechanism within Nova to automatically 
authenticate against the VNC console an instance
(I'm talking about plain old VNC authentication) or to generally prevent 
unauthorized local user accounts on the compute-node from accessing the 
VNC console of an instance?

I understand that nova-novnc proxy and websockify bridge between the 
public network and the private internal/infrastructure network of the 
compute-node using wss:// to secure and encrypt the connection over the 
public network. I also understand that VNC authentication is 
comparatively very weak....

This is perhaps only an issue when the compute-node is also permitting 
traditional Unix type user logins.
Let's say we have an instance running on the compute-node and the 
hypervisor or container manager serves out the console over VNC on a 
known port and the tenant has authenticated and logged in on the console 
using Horizon, perhaps as the administrator. A local user on the compute 
node, if they specified the correct port, could in theory then access 
the console and the administrative account of that instance without 
needing to authenticate.

VNC authentication using password (and optionally username) would seem 
like the traditional way to prevent such unauthorized access. I can't 
find anything within the Nova code base that seems to cater for password
authentication with the VNC server. For example the vmware nova driver 
returns the following dictionary
of parameters for an instance console in vmops.py:get_vnc_console():
                {'host': CONF.vmware.host_ip,
                 'port': self._get_vnc_port(vm_ref),
                 'internal_access_path': None}

No suggestion of a password to authenticate with the VNC server. Is this 
intentionally not supported, lacking, or is there perhaps simply a 
better way to address this problem?

Thanks in advance!
Niall Power

More information about the OpenStack-operators mailing list