Table of Contents
Although you can use a single RightScale account for managing all aspects of your company's cloud deployments there are a lot of advantages of using multiple RightScale accounts. As a best practice, it's recommended that you use at least two different RightScale accounts, although you may choose to have multiple RightScale accounts depending on your organization's IT cloud requirements.
Example: Using a Single RightScale Account
If you only use a single RightScale account, each user will have the same permissions across all deployments. Since you'll most likely have multiple projects organized into different deployments, you'll be forced to rely on users to essentially govern themselves since permissions cannot be granted on a per deployment basis. Although smaller teams may find one RightScale account sufficient for managing all aspects of their cloud infrastructure(s), most organizations will benefit from the extra control of using multiple accounts for better governance and compliance. Hopefully the examples below will clearly explain the advantages and disadvantages of each type of setup. Every team and organization has a unique set of requirements and objectives. You can either mimic one of the setups below or create your own setup based on the considerations and guidelines highlighted below.
Example: Using Two RightScale Accounts
Things to Consider
Example: Using 3+ RightScale Accounts
Use additional RightScale accounts for more granular user access control.
The configurations below apply to a single RightScale account. If you are using multiple RightScale accounts, you should follow the guidelines below for each account.
The appropriate answer to this question depends on your overall setup. The name of your account might be inconsequential to you, especially if you only have access to a single RightScale account. However, if you are managing multiple RightScale accounts, which is the preferred setup for many companies, you may find it useful to devise a more logical naming convention to clearly distinguish accounts from one another. Be sure to keep names short and simple. It's important to remember that account names are truncated after the 10th character and that accounts are listed in alphabetical order in the Dashboard's account dropdown menu.
The person who created the RightScale account is designated as the initial "owner" of the account. However, it can be changed if a different person is maintaining the account going forward. Users with 'observer' access may look up the "owner" of the account in order to request additional privileges or to change an account-wide preference.
Other than being designated as a primary contact person for end-users, an account's owner has no special privilege; anyone with the "admin" role is capable of performing all administrative functions within the account.
Note: The "Organization Name" is set in a different section of the Dashboard. If you have 'publisher' user role privileges, you can set the name under Design > Account Library > Your Publishing Organization.
This service is enabled by default and sends the email notifications to the account owner. If you do not want anyone to receive email notifications when an instance becomes available, you can disable this setting. If you want the emails to go to an email alias instead of one person (e.g. email@example.com) you will need to make firstname.lastname@example.org a user of the RightScale account and make email@example.com the owner of the account. (See the previous section.)
Before you can answer that question you may be wondering, "What are server tags and how are they used?"
RightLink-managed cloud instances can perform various automation tasks involving tags. Some example use cases for tags:
The tag scope for a deployment determines how the tags of its instances can be accessible and used by other instances located inside or outside of its deployment. By default, the scope is set to "deployment," which means that only the instances within that deployment will be returned in query results. Similarly, scripts that are executed on instances based on tags can only be performed by other instances within the same deployment.
If you change the tag scope to "account," instances within the deployment become accessible to instances located in all other deployments within the account, both for purposes of executing scripts and querying tags. Tag scope is a powerful but advanced setting that should only be changed by an experienced RightScale user who has a strong understanding about how tags are used in the context of the RightScale account.
You clone a production deployment to create a staging one for testing purposes. If the production deployment had a server array configured for auto-scaling purposes and you didn't change the voter tag for the staging deployment's server array, the server tag scope setting could potentially affect the production deployment's ability to auto-scale. If the tag scope is set to "deployment" (default), servers launched within the cloned deployment cannot affect auto-scaling in the production deployment. If the server tag scope of either deployment is set to "account," the production and staging arrays will influence each other's scaling decisions!
You have a deployment that contains servers that perform some global function in your multi-deployment application, such as system log aggregation. You set the deployment's tag scope to "global," and instances in any deployment can query for the log aggregator's IP address, run scripts to register themselves as log senders, etc.
Any changes to the server tag scope setting will immediately be applied to any running servers. Be sure to understand the implications of an update prior to changing this setting.
deployment (default) - If selected, a server's tags will only be accessible to servers and/or resources within its deployment.
account - If selected, a server's tags will be accessible to servers and/or resources outside of its deployment. This is an advanced option and should only be selected in specific use cases.
By default, each RightScale account is configured so that any user (with 'observer' user role privileges) can view billing related information such as estimated cloud usage costs. For example, users will be able to see the cloud Usage Estimate Report (Reports > Usage Estimate), deployment budget estimates in the Deployment Budget Estimate widget, as well as access to more detailed billing information in the RightScale Cloud Analytics site. This type of information is especially useful for users who are actively launching and managing servers for a deployment to keep track of their estimated infrastructure costs in order to stay within the allotted budget. However, if billing related information should only be viewable for select users, such as Project Managers and not Software Engineers, Enable the Admin-only Billing preference for the account, which will only allow users with 'admin' or 'billing' user role privileges to view billing related information. Note: Only users with 'admin' user role privileges can change the billing setting for the account.
By default, when you manually execute an operational script from the RightScale Dashboard (not API) you will be presented with an Inputs Confirmation page which displays the inputs and values that will be used by the script. The Inputs Confirmation page gives you an opportunity to verify what value will be used by an input, as well as the option to change its value prior to a script's execution. Typically, you should find that values for most inputs were previously set using input inheritance rules at either the ServerTemplate or Deployment levels. (See Inheritance of Inputs.) However, there may be situations when an input is unspecified or it may need to use a different value for a particular run. If a value for an input is required and missing, you will not be able to execute the script until you've specified an acceptable value. (Note: You can only select the 'No value/Ignore' option for an input that's not required (i.e. Recommended or Optional).
If you are using versions of ServerTemplates published by RightScale, it's recommended that you keep the default setting, which shows you the Inputs Confirmation page because there are some scripts that are designed with the assumption that the end user sees the confirmation page. For example, the recommended way to safely terminate a database server that's launched using a version of RightScale's 'Database Manager for MySQL 5.x' ServerTemplates is to run the db::do_delete_volumes_and_terminate_server operational script instead of using the Terminate button to ensure that detached volumes are properly deleted upon instance termination instead of simply being detached and left in an orphaned (and potentially billable) state. When you run the terminate script, you have the option to manually remove the "terminate safety lock" which prevents the data volumes from being permanently deleted after they are detached from the instance being terminated. See Terminate Database Servers.
Follow the steps below to specify the desired behavior for displaying the Inputs Confirmation screen for the RightScale account.
RightScale uses role-based authorization to determine who can perform which actions in an account. Our platform has a fixed number of named roles, each of which confer a bundle of related capabilities on users who have that role. For example, the 'server_login' role allows people to log in to instances via SSH or RDP.
Roles are always held by a specific user, with respect to a specific RightScale account; we call each (user, account, role) trio a permission. Permissions can be granted or revoked by anyone with the 'admin' permission on an account. A user with one or more permissions in an account is considered to belong to that account; if their last permission is revoked as they no longer belong to the account.
It's important to understand the capabilities that each role bestows upon a user; capabilities are almost always disjoint (non-overlapping) between roles. For example, only someone with the 'actor' permission can launch and terminate servers; only someone with the 'designer' permission can modify ServerTemplates.
'observer' is the least powerful role; it allows a user to log in to the RightScale account and see its cloud resources, design objects and other entities within the account itself, but it does not allow the user to interact with anything. For example, a user can see a server, but cannot terminate it or execute a script. In practice, users cannot do anything in an account unless they have the 'observer' permission. Note: A user must have at least 'observer' privileges before he/she can be granted additional roles.
admin' is the most powerful role; it allows a user to invite other users to the account, and to edit the permissions of existing users including other users with 'admin' privileges and even themselves. Users with 'admin' permissions can grant/revoke permissions from any user including themselves, as well as permanently remove a user from the RightScale account. It's very important that you only grant 'admin' to users whom you trust completely.
We suggest that you review the following pages before you begin inviting new users or granting additional permissions to existing users:
When you are ready to add users to a RightScale account, you can send them an invitation to the account. Invitations are sent via email and must be accepted by the user before they can log in to the Dashboard and view the RightScale account.
From the time an invitation is sent, it must be accepted within six days or it expires. You can also cancel an existing invitation at any time before it is accepted.
If a user has already accepted an invitation to your account, you can grant them new permissions or revoke existing permissions at any time, in any combination.
You can also grant temporary access to a user (such as a short-term consultant) or grant an existing user an additional permission(s) that will automatically expire after a specified amount of days. For example, you may want to give additional permissions to developers during a site upgrade.
Let's say your company has two RightScale accounts.
In this example, Ben's position within the company entitles him to interact with both accounts; however, his level of access in each account is very different. Although he can view the Production account, he cannot launch any servers or create any scripts. But in the Dev & Test account, he can modify ServerTemplates, launch and terminate servers, and login to running servers for troubleshooting purposes. We would enact this access policy by granting Ben the following permissions:
(For Amazon Web Services EC2 only)
Yes, absolutely. It's important to remember that IAM restrictions are tied to a specific set of user security credentials. (i.e. AWS Access Key ID and AWS Secret Access Key) Since you can only apply a single set of security credentials to a RightScale account (when you Add AWS Credentials to RightScale), the restrictions are enforced at the account level and not at the individual user level. Therefore, if you create an IAM user role that's only allowed to launch and terminate instances and use its security credentials with a RightScale account, users will only be able to launch and terminate instances from the RightScale Dashboard/API (assuming they have 'actor' user permissions) and will not be able to create/modify security groups even if they have 'security_manager' user permissions in the RightScale account.
For more information, see How do I use Amazon IAM with RightScale?
There are several different ways that you can protect your running servers. You should use some or all of the available tools to satisfy the requirements of your company's SLA and related security policies.
Use the following user role permissions to control who has remote access to running servers in an account.
Warning! Only trusted users should be given the 'server_superuser' permission. It's ultimately your responsibility to protect your infrastructure from any type of malicious activity. Once a user has this permission, he/she can 'root' the filesystem and install malicious code that may go unnoticed or be undetectable. If you need to revoke this permission from a user or remove a user from a RightScale account that had the 'server_superuser' permission at one point in time past, see Remove Users from a RightScale Account in order to mitigate the risk of having a compromised server.
(For Linux only)
For clouds that support the use of SSH Keys (e.g. AWS), those keys can still be used to SSH into an instance by anyone who possesses the private key material. Moreover, cloud-provided SSH keys are installed in the root user's authorized_keys file, making these keys very powerful indeed! However, you can disable the use of the cloud's SSH key by enabling the "Mandatory Server Login Control" setting on your account.
There are several reasons why you should consider enabling this setting for your account.
Enabling Server Login Control will give you the following benefits.
When you log in to the RightScale Dashboard for the first time you may not have noticed that RightScale automatically generated a unique SSH keypair for you that's used for authentication purposes when you initiate SSH sessions from the RightScale Dashboard. RightScale's server login control is designed to provide a secure and cloud-agnostic method for allowing remote access to running instances via SSH.
Go to Settings > User Settings > SSH tab to view your public SSH key. If you want to use a third party client to SSH into an instance you can download the matching private key.
RightScale's Server Login Control policy is a user setting and cannot be enforced at the account level. Users have the option to either use the unique keypair that RightScale generated for them or create their own SSH keypair and manage it themselves. (See Manage an SSH Key Pair.) If your users are required to use their own SSH keypair in order to comply with your company's security policies and procedures, it's recommended that each user generate and manage their own keypair. SSH keys should only be known to an individual user for security reasons.
* Supported in images using RightLink v5.9+.
** Supported in images using RightLink v5.8+.
You are the only person who should know or have access to your SSH keypair (matching public and private keys). If you think your keypair has been compromised in any way you should create a new SSH keypair immediately.
Note: RightScale will not generate a new SSH keypair for you. If you re-enable the Server Login Policy setting, you will be granted the same SSH keypair.
Another way that you can control who can SSH/RDP into an instance is by using more restrictive cloud-level and OS-level network firewall rules, as applicable. The first layer of security is at the cloud infrastructure level using security groups. For Linux instances, you can also use iptables to create an additional (and optional) layer of firewall security that's enforced at the instance level. For clouds that do not support the use of security groups, you must rely on iptables for firewall security.
If a cloud supports the use of security groups (e.g. EC2, Google, CloudStack, OpenStack, etc.) you can use security groups to define more restrictive port permissions that are IP-specific instead of allowing access from any IP (0.0.0.0/0)
For example, you could create a security group permission that only allows SSH access from a specified subnet mask (e.g. CIDR 54.197.0/16). Or perhaps you only want users to SSH into an instance from company provisioned laptops.
(For Linux only)
ServerTemplates published by RightScale (v12+) include support for iptables. Each ServerTemplate uses tags and iptables to create IP-specific firewall rules, which are typically used to set up isolated tier-to-tier communication depending on the desired functionality of the server. For example, an iptables rule can be dynamically created on a master database server which allows ingress communication from an application server's private IP address that was just launched (assuming it's been assigned an IP address).
Refer to the individual technical overviews for a ServerTemplate for a better understanding of how iptables are used to create firewall rules. (e.g. PHP App Server (v13 Infinity))
The RightScale Management Platform (Dashboard and API) supports the infrastructure-as-a-service ("IaaS" or "compute") capabilities of the following clouds:
You should only add clouds that you plan to use in your RightScale account. You can only add a cloud with a unique set of cloud credentials. A set of cloud credentials cannot be shared across multiple RightScale accounts. Therefore, if you are using multiple RightScale accounts you must use different and unique cloud credentials for each account. Although you can build hybrid cloud deployments that are spread across multiple clouds for high availability and disaster recovery scenarios, you will experience the most optimal performance if your software stack is deployed within the same cloud infrastructure and region. Obviously, this rule doesn't apply to datacenters/zones within a cloud/region as spreading your site's architecture across multiple zones/datacenters is a recommended best practice in the cloud.
Only users with 'admin' user role privileges can associate a cloud account with a RightScale account.
Pick the cloud that's best for you!
Remember, each application that you deploy in the cloud has a unique set of cost and performance requirements. Cloud infrastructures are equally unique and offer a wide range of resources and services. Ultimately, you should pick the cloud that's best suited for your application.
One of the key advantages of using the RightScale platform is that you can build cloud-agnostic ServerTemplates for your application. Launch and test your application in multiple clouds. Perform all of the necessary benchmark tests so that you can confidently select and deploy your software stack in the cloud that gives you the best performance and ROI. And if the net results ever change, you'll have the flexibility to easily migrate those applications to a different cloud of your choice.
By default, users can access a RightScale account (via the web Dashboard or API) using their email and password from any location (i.e. public IP address). However, there are a few different ways that you can enforce stricter login policies. For example, you can control how a user accesses a RightScale account as well as from where he/she is allowed to access it.
E-mail and Password
By default, users must use their email and password to log in to the RightScale Dashboard or authenticate a RightScale API call.
Single Sign-On (SSO)
RightScale supports the use of Security Assertion Markup Language (SAML) for using a Single Sign-on (SSO) identifier/token for accessing a RightScale account via the Dashboard and/or API. RightScale supports both types of SAML providers.
All users can specify how they want to authenticate themselves with the RightScale Dashboard and/or API under Settings > User Settings > Authentication. By default, you will use your email and password for authentication purposes. However, if you prefer to use SAML-based authentication, you can change the default authentication method to use Single Sign-on instead where an SSO Identifier is used for authentication purposes instead of your regular password.
Important! If you enable SSO, you must also Enable OAuth to authenticate API calls.
Enforce Single Sign-on (SSO) for Dashboard Access
If you want to disable a user's ability to log in to the RightScale Dashboard or authenticate an API call using their email and password, you can contact your RightScale Account Manager and request that the "Mandatory Single Sign-on" preference be 'Enabled' for your RightScale account, which effectively disallows a user from being able to use their email and password for authentication purposes. If enabled at the account level, all users will also be required to Enable OAuth for API access.
There are several different ways that you can control access to your RightScale account an its resources via the API.
By default, you can construct a RightScale API call using your email and password for authentication purposes. However, if you prefer to use an OAuth token instead of your email and password, you can enable the OAuth feature. See OAuth.
The ability to authenticate your RightScale API calls using an OAuth 2.0 token is a user setting that can enabled on a per account basis.
Enforce OAuth for API Access
If you want to disable a user's ability to make API calls using their email and password for authentication purposes, you can contact your RightScale Account Manager and request that the "Mandatory Single Sign-on" preference be 'Enabled' for your RightScale account, which effectively disallows users from using their email and password to make API calls. If enabled at the account level, all users will also need to set up SSO (SAML) and use their SSO Identifier to log in to the RightScale Dashboard.
If your users should only be allowed to access the RightScale Dashboard from on-premise laptops, you can use a set of IP Whitelists to define a valid list of IP addresses or range of IPs. In such cases, you can can restrict access to your RightScale account by enforcing a list of approved IP addresses or IP range(s) using CIDR rules.
Define a specific range of (public) IP addresses from which users or services can access a RightScale account and its managed resources. For example, perhaps users should only be allowed to access the RightScale Dashboard from a specific on-premise location or maybe a service running inside your local infrastructure needs to issue RightScale API calls.
If your RightScale account has multiple users who are creating and launching servers, you may find it useful to set some account-wide default settings. Currently, you can specify default settings for adding servers to a deployment. For example, maybe you want to minimize your cloud infrastructure costs by encouraging your users to only use the 'small' instance types for development and testing purposes because they are cheaper and sufficient to perform the required software quality assurance tests. Or perhaps you purchased a block of discounted instances (e.g. EC2 Reserved Instances). Therefore, it's in your best interest to encourage your users to launch instances at the discounted rate in order to optimize your cloud infrastructure usage and related costs. In such cases, you can specify various default configurations that will be inherited (i.e. pre-selected) when a user creates a new server/array and adds it to a deployment.
The example screenshots below demonstrate how two server defaults for the 'AWS US-West' cloud are inherited and pre-selected when you use the Add Server wizard to create a server.
Server defaults are cloud-specific and are designed to encourage (not enforce) server configurations. The server defaults are only applied when a user creates a new server. The settings are not retroactive and will not affect any previously defined servers that are active or inactive. Server defaults can only be applied to servers that are created using ServerTemplates using the Add Server wizard in the Dashboard.
Important! A user will still be able to override a server default setting and make a different selection. However, you can use server defaults to define your preferred server configuration settings and then enforce these preferences using your own set of internal policies and procedures to ensure that your users are using the predefined server defaults, as necessary. Be sure to perform account-wide audits on a regular basis to enforce your configuration guidelines.
Only users with 'admin' user role privileges can define server defaults for a RightScale account.
If you are using multiple RightScale accounts for your organization, read the sections below to understand how you can properly set up multiple RightScale accounts so that you can effectively share and reuse assets between them for effective collaboration. For example, you might need to share account-specific assets (e.g. ServerTemplates, Images, etc.) across different accounts because you're developing ServerTemplates in one account and deploying them in your production environment that's in a different account. In such cases, you can set up your accounts so that the ServerTemplate functions in a slightly different way depending on the account in which it's used, which is especially useful for hiding sensitive values such as passwords that are only used in your production environment. Each scenario will be described in more detail below.
Things you can share between RightScale accounts:
* If supported by the cloud. For example, images and snapshots can be shared between AWS accounts. Since cloud credentials can only be mapped to a single RightScale account, these types of cloud resources can be considered account-specific assets similar to ServerTemplates.
Determine who is in charge of the sharing process and make sure they have 'publisher' user role privileges, which is required in order to facilitate the sharing process between multiple RightScale accounts.
To learn how you can share RightScale components and Cloud resources, see our Publishing and Sharing guide.
As a best practice, you should use credentials (Design > Credentials) to hide sensitive values from being visible to your users while still making the value accessible to your configuration scripts. If you are managing multiple RightScale accounts (e.g. Production, Development & Testing, etc.) a helpful way to use credentials is to create ones with the same name across all RightScale accounts, which will allow you to use the same immutable, committed revision of a ServerTemplate across multiple accounts, where different values are used in each account.
For example, you can use a different password value in the Production account than in the Dev & Test account, which is especially useful if you're developing and testing ServerTemplates in a different account than the account you're using for your production environment. Remember, user role permissions are account-specific. Therefore, custom ServerTemplates can be developed in the Dev & Test account where your software developers can create and use credentials with their own passwords for development and testing purposes. But once those same ServerTemplates are locked down, tested, and ready for production-use, you can share committed revisions of those templates with the Production account for deploying your production servers. Except when they're used in the Production account (where the software engineers do not have access), the ServerTemplates use credentials with secure passwords that are only known to you and your Operations team.
© 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.