Using security groups to tighten OpenStack security
One of the great features of OpenStack (and therefore our Fuga service) is the use of security groups. With security groups you’re able to very precisely define access rules to your platform and instances. In essence, they give you a free, fully customizable firewall. In this article we’ll tell you how you can use customized security groups to grant access based on the roles of the instances within your Fuga platform.
How do security groups work?
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.
The Fuga default security group
For every Fuga project a default security group is available. Unless you overrule this, the security group has the following rules:
- Deny all inbound traffic (Ingress) from the internet
- Allow all outbound traffic (Egress) from your instances to the internet
- Allow free communication within your internal network
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.
Using customized security groups
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.
Example: a webserver and database server
For this article, we demonstrate the use of security groups using a simple setup of a webserver and a (MySQL) database server. The webserver is the only forward facing server and uses a MySQL client to connect to the MySQL server. The webserver 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 webserver 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 webserver.
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:
- internal: for internal ssh and ping between instances on the internal network
- external: for external connections (ssh and ping) from the internet
- www: for http and https traffic to the webserver
- dns: for dns resolving of the servers with their specified (Google) nameservers (from resolv.conf)
- mysql_server: to allow incoming connections to the mysql server from the client
- mysql_client: to allow outbound connections from the mysql client to the server
Click the screenshots below to view the actual configuration we made. 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.
Activate the security groups on your instances
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.
Or…use the API
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.
Find out more about our Fuga platform and service at Fuga.io.