On Sat, Apr 21, 2012 at 9:40 PM, Kelven Yang <[email protected]> wrote:
> Token issuing process here does look similar with Kerberos ticket issuing > process, however, the access token we issue in CloudStack management server > not only contains authentication information alone, but also other > information that is essential to contact to the hypervisor VNC server. For > all the involved parties, management server, console service VMs and > hypervisor hosts, not all of them can freely participate Kerberos session. > Balance it with the goal of just securing access-info in URL and the > complexity of Kerberos deployment brought into the picture, we haven't > looked into it. > > > Understood. Thanks for the background Kelven. > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Alex > Karasulu > Sent: Saturday, April 21, 2012 2:02 AM > To: [email protected] > Subject: Re: Security aspects of CloudStack console access > > 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 > -- Best Regards, -- Alex
