Security groups are sets of IP filter rules that you can apply to all instances within your Fuga project. They define networking access to the instance. These rules are project specific; you can edit the default rules for your group and add new rule sets. They encompass both access within your platforms and communication with the internet.
Security groups are applied to your instances. Every instance can have its own specific set of applicable security groups.
For every Fuga project, a default security group is available. Unless you overrule this, the security group has the following rules:
It's a good set to start with, but you may want to create further restrictions.
Because you have to open inbound traffic yourself first, your shield is up from the start. You have to open ports yourself to even access your own platform from the outside. Our Getting Started tutorial series shows you how to do that.
However, because by default no internal restrictions apply within your Fuga project, a security breach on one of your instances can potentially have an impact on all other instances. This is a reason you may want to impose more rules. The free communication to the outside world is a potential boon for DDoS attackers who manage to exploit a weakness on one of your instances. So, let's see how we can improve upon the default configuration.
One of the ways to define security groups is based on roles you want to assign to instances. Instances with public IP addresses will probably run different services than those that don't and, accordingly, may have different access requirements (both inbound and outbound). By creating new security groups and rules, you can create any configuration you want.
To create a new security group, go to 'Compute', 'Access & Security' and click 'Create Security Group.' Choose a name and description for the security and click 'Create Security Group' to finish. You can then add rules to the new group by selecting 'Manage Rules' from the security group overview.
For this article, we demonstrate the use of security groups using a simple setup of a web server and a (MySQL) database server. The web server is the only forward facing server and uses a MySQL client to connect to the MySQL server. The web server needs to be publicly accessible through SSH and HTTP/HTTPS. For simplicity's sake, we chose not to apply IP restrictions on SSH access in this example. The web server also needs to be able to make outbound connections to the MySQL server. The MySQL server itself has no external IP address and only needs to be accessed through SSH and the MySQL client on the web server.
If you remove the default security group from an instance, all access is forbidden. That's a great start. Now add what you need.
For this example, we decided to create six new security groups:
View the actual configuration we made in the screenshots below. Please note that the mysql_server group restricts access to just the mysql_client group and vice versa. The internal group restricts access to other instances within the same security group only.
After we created the security groups above, we assigned them based on the roles of the specific servers. You can add them to your instances through 'Compute', 'Instances' and then selecting 'Edit Security Groups' in the 'Actions' pull-down menu. The screenshots below show the security groups for each instance.
In this case, we created and configured the security groups using the Horizon dashboard. You can, of course, use the OpenStack API or CLI tools as well to get the same results.
The OpenStack website has documentation to help you get started:
The example above is very basic. We’ve done this setup with Ubuntu servers, that in this scenario can’t even access software repositories to perform updates and install new software, because outbound port 80 is blocked. You'll probably want to add that. Other software on your instances may also require additional rules and/or groups.
Furthermore, don't mess around with security groups on a production platform, but do it before you go live. Or test it thoroughly on a test environment. There are always dependencies you may not have thought of, which may cause services and applications to stop working.