incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Kinsella <>
Subject Re: Security aspects of CloudStack console access
Date Sat, 21 Apr 2012 01:47:43 GMT
I understand you're limited by VNC's setup, but DES is considered a "broken" crypto algorithm,
and it'd be in our best interests to get something stronger in place in the future...I'll
probably offer customers VNC over VPN.

And regarding SSL, that too is more or less crippled. Security needs to take a layered approach,
so that if one layer is compromised (see: malicious organizations being issued CA certs and
therefore the ability to create any SSL cert they want) other layers will still prevent malicious


On Apr 20, 2012, at 5:58 PM, Kelven Yang wrote:

> 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

Stratosec - Secure Infrastructure as a Service
o: 415.315.9385

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message