incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kelven Yang <kelven.y...@citrix.com>
Subject Security aspects of CloudStack console access
Date Sat, 21 Apr 2012 00:58:19 GMT
>From time to time, we received a number of emails from security experts who want to raise
concerns about accessing the guest console. We've listened and started to address these security
concerns in upcoming releases. I'd like to throw a brief introduction in this area and would
like to gather feedbacks from CloudStack development community.

1. Design principal of CloudStack console access service

   a) Separate control path and data path
	CloudStack Management server manages control traffic, console service VMs manage data (access)
traffic. Which means that as soon as CloudStack management server has helped setup the access
session, it will go out of the picture. A access session will be solely conducted within a
console service VM from then on.

   b) Console service VM is stateless
	Console service VM works in stateless mode, this is to allow an easy scale-out solution.
CloudStack management server will automatically launch necessary service VMs based on current
system load. A stateless service VM leads to the design of having management server to help
negotiate, authenticate and setup the access session.

2. How it works
To start a console access session, management server first generates an access token, assigns
a service VM instance, and then redirects client browser (in a new window) to initiate the
session to the target service VM with the access token.

When service VM receives the access request, it relays the authentication request to management
server presenting the token passed from client browser. At this phase, if management service
is running as a CloudStack management server cluster, the request may be relayed to a different
management server instance other than where the original token was generated on.

If the request can be authenticated successfully, an access session will be open in the service
VM. After this point, user will be able to access the guest VM via a AJAX viewer sent from
the service VM to client browser.

3. Security aspects
	a) Passing access token.
	We originally rely on management server secured web session to protect the access info, the
access info appears in clear text in browser url. A lot of people have raised concerns of
this. To address the concern, we now wrap the access information into an DES encrypted access
token, DES encryption key is randomly generated at per CloudStack installation basis. The
DES encryption key will also be passed to console service VM via our SSL-enabled agent/management
server channel so that service VM would be able to continue performing security validation
after management server has gone out of the picture.

Access token is also time-stamped by management server. Session authentication should happen
within the time period, otherwise, access will be declined. If management service is running
as a management server cluster, all management server instances have to be time-synced.

	b) Securely access to hypervisor VNC sessions
	We recently added support to use XenServer secure access API to secure the traffic between
console service VM and XenServer host. For KVM/VMware, a random generated hypervisor password
will be included inside the access token, console service VM uses the information to setup
the security within the VNC protocol framework.

I hope I have done a good explanation work, if you do have further security concerns, please
feel free to drop your feedback on this to the list.

Kelven


Mime
View raw message