On Sat, Apr 21, 2012 at 6:45 AM, Kelven Yang <[email protected]> wrote:
> Access token is exactly another added layer, the first security layer is > provided through HTTPS web session. Second layer is the dynamic access > token, third-layer is the timely expiration of access token. > > The flow and use cases I'm seeing here seems ideal for a Kerberos solution. Were there any thoughts along these lines for some of these security issues? > -----Original Message----- > From: John Kinsella [mailto:[email protected]] > Sent: Friday, April 20, 2012 6:48 PM > To: [email protected] > Cc: Development discussions for CloudStack > Subject: Re: Security aspects of CloudStack console access > > 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 > use. > > John > > 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 > @johnlkinsella > > -- Best Regards, -- Alex
