This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • Security aspects of CloudStack console access
Skip to end of metadata
Go to start of metadata

1. Design principal of CloudStack console access service

Separate control path and data path

 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.

Console service VM is stateless

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

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.

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.

  • No labels