Note: Please go to to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > Clouds > CloudStack > Exposing your CloudStack Cloud to RightScale

Exposing your CloudStack Cloud to RightScale


  • URL of the CloudStack server.
  • Both the API Key and Secret Key of an account generated by the administrator of the CloudStack instance.


For a cloud to be properly supported by the RightScale management platform, certain components need to be configured. The following provides details to ensure your CloudStack cloud is properly configured to interact with RightScale.

Enable Inbound Traffic to RightScale

The URL of the CloudStack API should resemble the following structure:

http://<PUBLIC_IP>:443/client/api (SSL)


Make sure access to the API is possible by opening up port 8080 (443 for SSL) to the CloudStack Management Server's PUBLIC_IP address. This enables inbound traffic between RightScale's services and the CloudStack Management Server. Note that various ports also need to be open from the CloudStack compute nodes out to the Internet. This is because the running servers within your CloudStack cloud will need to have access to RightScale through various ports. For more information, see CloudStack Reference Architecture

Through the usage of HTTPS and certificates, essentially a simple VPN is established between RightScale and your CloudStack cloud.Therefore, your CloudStack API is only exposed to RightScale and not the entire Internet.

Configure a Firewall

It is strongly recommended to have a firewall configured to allow access.

To configure this, allow HTTPS communication between our gateway and your CloudStack Management Server so RightScale can make calls to the Cloud Controller API (which reports the status of your CloudStack cloud). Contact RightScale to receive a whitelist of IP addresses from which the Cloud Management Server must accept requests. For information about whitelisting the inbound communications to the CloudStack Management Server, please see Private Cloud Network Connectivity Requirements.

Network Architecture


From a cloud networking perspective, a cloud must have the basic networking that provides the following functionality:

  • Ability for RightScale to access user data and metadata
  • Defined Subnets

Network Communication



  • Ingress Communication - Requests from RightScale to the cloud
    • TCP: 8080
  • Egress Communication - Requests from the cloud to RightScale
    • TCP: 80 (HTTP)
    • TCP: 443 (HTTPS) 
    • AMQP: 5672 (Messaging between RightScale core and an instance)
    • UDP: 3011 (Monitoring)
    • UDP: 514 (Syslog--Log Data)
    • UDP: 123 (Network Time Protocol)  

See RightLink Ports and Protocols.

Basic Networking

Basic Networking (previously called Direct Networking) utilizes physical routers to handle virtual machine network traffic similar to a traditional networking model. There is no support for VLAN and guest isolation is achieved through the use of security groups. Basic Networking configuration is simple and commonly used by organizations that are a sole tenant to the cloud infrastructure as traffic isolation is not a concern. It is most similar to EC2 networking and fully supported within RightScale. 

  • Internal RFC 1918 IP Addresses for virtual machines
  • (1) Public or NAT'd available IP Address that RightScale uses to communicate with the Cloud Management Server (also known as the Cloud API Endpoint)
  • Basic networking configuration (Flat Direct Untagged networking; No VLAN's or Virtual Router configuration)
  • Converged User, Management, and Storage networks (no separate NIC's or VLANs)
  • Connectivity to the Internet
    • Ingress - Inbound traffic between RightScale's services and the Cloudstack management server. Contact RightScale to receive a whitelist of IP addresses from which the Cloud Management Server must accept requests.
    • Egress - Although an instance does not have to accept web requests from the Internet, it must be able to send requests to RightScale services. 
  • (Optional) A hardware firewall controlling ingress Internet connectivity.

Advanced Networking

Advanced Networking implements VLANs in addition to security groups for increased guest isolation. This is typically used by service providers or those that need to provide network isolation. The physical network topology must support VLANs. Users can create VMs with one or more networks attached. With Advanced Networking, guest isolation options include:

  • None - Using Advanced Networking without a VLAN is like using Basic Networking. Any guest isolation is defined by the provider at the physical level based on how they trunked in their network. Some service providers use this type of setup to provide MPLS support for their exclusive customers. Generally, with this model, you must select a VLAN to place your VM on.
  • VLAN - With VLANs, a system virtual router is created per CloudStack account and acts as the default gateway and firewall between a pre-configured Public Network (real public IPs) and a private guest network that is isolated from others via the use of a VLAN. With VLANs, IP forwarding rules must be set in order to access VMs from the Internet. With this model, the virtual router enables load balancing (you can route traffic as defined in your NAT or port forwarding rules), you get VPN support (port forwarding rules) and firewall (port forwarding rules (or lack thereof)).
  • Security Groups - With Security Groups, guest isolation is achieved via Security Groups but the physical network topology is backed by the use of a VLAN rather than a flat/untagged network similar to the Basic Network.
    Note: Security Groups on VLANs currently only work on KVM.
    • Security Groups are supported the same way as Basic Networking configurations, except they function on top of VLANs.
    • Static 1:1 NAT [IP Forwarding rules] are set up to forward public traffic to virtual machines.
    • Port mapping rules (with and without 1:1 NAT).

IPs and Protocols

The Cloud Management Server must be able to accept requests from RightScale services.

Cloud API Endpoint Security

API Rate Limiting

Some cloud providers want to limit how frequently a consumer can make API requests to the cloud. RightScale does not support limiting cloud API requests and strongly discourages against this practice because it creates a bad end user experience for cloud consumers.

API Restrictions

Some cloud providers want to limit API calls that can be made by known cloud API consumers. 

If a RightScale user manages a CloudStack using the RightScale Dashboard/API, all of the API calls to the cloud will come directly from RightScale. RightScale does not put any limitations or restrictions on which API calls are allowed.

IP Whitelisting

Some cloud providers want to block external API access from unknown IP Addresses. As a result, they require RightScale to provide all IP Addresses from which access to the cloud is required.

RightScale does not recommend or approve this method. RightScale can provide IP addresses, if absolutely required. However, RightScale's Operations team has the ability to change IP addresses (as required) for elastic scaling. It is recommended that you configure your firewall to allow access from our fully qualified domain name. Although downtime might occur if we need to change our DNS records, it is a more reliable method than whitelist of IP addresses. Please consider IP Whitelisting as a security method as a last resort.

Endpoint HTTPS

RightScale requires HTTPS endpoints for any supported cloud.

Optionally, RightScale also supports a mutual authentication mechanism that we can deploy on a case-by-case basis. Please let us know if you are interested in learning more about this method. 


You must to post a comment.
Last modified
10:14, 24 Apr 2014


This page has no custom tags.


This page has no classifications.



© 2006-2014 RightScale, Inc. All rights reserved.
RightScale is a registered trademark of RightScale, Inc. All other products and services may be trademarks or servicemarks of their respective owners.