Security groups are network rules that allow instances in one tenant (project) be kept separate from other instances in another. Managing security group rules for our OpenStack instances is done as simply as possible with OpenStack Dashboard.
Note
As described in the Creating tenants in Keystone recipe of Chapter 1, Keystone – OpenStack Identity Service, projects and tenants are used interchangeably and refer to the same thing. Under the OpenStack Dashboard, tenants are referred to as projects, whereas in Keystone, projects are referred to as tenants.
Load a web browser, point it to our OpenStack Dashboard address at http://192.168.100.200/, and log in as a user, such as the demo user created in the Adding users to Keystone recipe of Chapter 1, Keystone – OpenStack Identity Service, with the password openstack.
To administer security groups under OpenStack Dashboard, carry out the steps discussed in the following sections.
To create a security group, perform the following steps:
- A new security group is added to our system by using the Access & Security tab under the Compute section, so click on it:
- Next we see a screen allowing access to security settings and managing key pairs. Under Security Groups, there will be a list of security groups that can be used when we launch our instances. To create a new security group, click on the Create Security Group button:
We are asked to name the security group and provide a description. The name cannot contain spaces:
- Once a new security group is created, the list of available security groups will appear on screen. From here we are able to add new network security rules to the new security group:
To add and remove rules, security groups can be edited by performing the following steps:
- When we have created a new security group, or wish to modify the rules in an existing security group, we can click on the Manage Rules button for that particular security group:
- After clicking on the Manage Rules button, we are taken to a screen that lists any existing rules and enables us to add new rules to this group:
- To add a rule to our new security group, we click on the Add Rule button. This allows us to create rules based on the different protocol types—ICMP, TCP, and UDP. There is also a list of rule templates for commonly added services. As an example, we will add in a security group rule that allows HTTPS access from anywhere. To do this, we choose the following:
- We select the HTTPS option from the drop-down menu. This returns us to the Add Rule menu where we can specify the source of the network traffic:
- When we click on the Add button, we are returned to the list of rules now associated with our security group. Repeat the previous steps until all the rules related to our security group have been configured:
- We can also add custom security rules for services that do not have built-in rule templates. After we click on the Add button, we choose the Custom TCP Rule option from the Rule drop-down list. Then we select the Port Range option from the Open Port drop-down list, which presents us with From Port and To Port fields. We enter a port range and click on the Add button:
- Note that we can remove rules from the screen associated with step 5 too. Simply select the rule that we no longer require and click on the Delete Rule button. We are asked to confirm this removal.
Security groups are important to our OpenStack environment, as they provide a consistent and secure approach for accessing our running instances. Allowing users to create, delete, and amend security groups to use within their tenants allows them to create secure environments. Rules within a security group are deny by default, which means that, if there is no rule for that particular protocol, no traffic for that protocol can access the running instance with that assigned security group.
Security groups are associated with instances on creation, so we can't add a new security group to a running instance. We can, however, modify the rules assigned to a running instance. For example, suppose an instance was launched with only the default security group. The default security group that we have set up has only TCP port 22 accessible and the ability to ping the instance. If we require access to TCP port 80, we either have to add this rule to the default security group or relaunch the instance with a new security assigned to it to allow TCP port 80.