Note: Please go to to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > Guides > Dashboard Users Guide > Clouds > Generic > Security Groups > Actions > Create a New Security Group

Create a New Security Group


To create a new security group (or groups) to use with servers in deployments.

Table of Contents


  • Adding and editing security groups requires the "security_manager" role.  See User Role Privileges.

Note: The "security_manager" role also enables you to run Infrastructure Audit reports (which include security group audit trail information).


If you are on a UCP account (Unified Cloud Platform), you will need to create security groups within the network manager. For more information, see Networks.


Security groups are essentially firewalls for servers in the cloud. They define which ports are open to allow incoming connections to a server via specific protocols. Security groups only affect ingress (incoming) communications and do not prevent a server from initiating outbound communications.

Each server must have at least one security group assigned. By default, a new security group set up with no associated rules will deny all access to its associated servers. You must add rules in order to allow inbound traffic to the servers.

Security groups give you a flexible way to restrict server access, allowing you to set restrictions specific to particular protocols, ports, IP addresses, or combinations of these. Permissions defined in a security group are additive in nature; so, if a server has two security groups where one group has port 80 open and the other group has port 80 closed, port 80 will be open (not closed) on the server.


Create a New Security Group

  1. Go to Clouds -> CloudName -> Security Groups -> New. 
  2. Provide the following information about the security group.


  • Name - Enter a descriptive name for the security group. (e.g. ProjectX)
  • Description - Provide a helpful description.  (Note: Required for OpenStack)
  • Permissions - Use the checkboxes to create firewall permissions for some of the common TCP ports. The created rule will allow ingress communication from any public IP address. (   Note: You can create additional firewall rules in the next few steps.
  1. Click Create

Add IP-based Permissions

All firewall permissions apply to ingress communication. Create a rule for a specific port or range of ports. Create additional rules as necessary. 

  1. If you are building a 3-tier deployment, see Create a Single Security Group for a 3-Tier Demo Deployment to verify that you are creating the appropriate firewall rules for your type of reference architecture.
  2. Go to the Info tab of the security group. Create a new firewall rule under the "Permissions" section.


  • Select the IP protocol (TCP, UDP, ICMP).  Note: For ICMP, use -1 as a wildcard (that is, all ICMP Types and Codes). 
  • Define the level of IP access using CIDR notation. For example, to allow any IP addresses, enter:
  • Define the port or range of ports. To open a single port, enter the port number in both fields. (Note: For OpenStack, the port must be greater than zero.)
  • Provide a helpful description for the firewall rule.
  1. Click AddWarning!  Changes to firewall permissions are applied immediately and will affect any running instances that are using the security group. 
  2. Repeat the steps above to add additional firewall rules, as necessary.


Add Group-based Permissions

Use the "Add Group" feature to add security groups to other security groups or to add a security group to itself. This feature grants group-wide access permissions that apply to all servers in the added group. See Add a Security Group to another Security Group or Add a Security Group to Itself.

Troubleshooting Security Groups

When experiencing communications issues with servers in a deployment, you may need to troubleshoot your security group settings. The following is a list of common issues often associated with the setup and configuration of security groups.

  • Ports not opened correctly
    • No website access? Port 80 may be closed.
    • SSH sessions fail? Port 22 may be closed. (For non-RightLink-enabled machine images, incorrect or absent SSH keys can affect operational and decommissioning RightScripts also.)
    • No SSL support?  Port 443 may be closed.
  • Accidental use of /32 in CIDR IP address notation, instead of a less restrictive /0.
  • If too many ports are open on your server, you may have specified a range of ports when trying to specify a single port in your security group (e.g., ports 80 through 8000 instead of only ports 80 and 8000).
  • If servers within a security group are not communicating correctly, you may need to either explicitly open the communications ports to all IP addresses, or add the security group to itself, which allows all servers in the security group to communicate with each other.
You must to post a comment.
Last modified
17:14, 13 Nov 2013



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.