You should also add this to the wiki.
________________________________________
From: Kelven Yang [[email protected]]
Sent: Friday, April 20, 2012 5:58 PM
To: [email protected]
Cc: Development discussions for CloudStack
Subject: Security aspects of CloudStack console access
>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
