AWS EC2 provides (enforces?) network port filtering. The filter rule sets are called securitygroups. AWS also offers two forms of EC2, "classic", and "VPC" (virtual private cloud). Managing securitygroups for classic and VPC are a little different. I'm going to present securitygroups in EC2-Classic. If you're going to use EC2-VPC, you'll need to read the Amazon documentation and adapt your processes to the VPC behaviors. Also note that securitygroups have a scope. They can be applied only in the region in which they are defined.
In EC2-Classic you must associate all of the securitygroups with a new instance when you launch it (create it from an image). You cannot change the set of securitygroups associated with an instances later. You can change the rulesets in the securitygroups and the new rules will be applied immediately to all of the members of the securitygroup.
Amazon provides a default securitygroup which basically restricts all network traffic to the members (but not *between* members). To make OpenShift work we will need a set of security groups which allow communications between the OpenShift Broker and the back-end services, and between the broker and nodes (through some form of messaging). We will also need to allow external access to the OpenShift broker (for control) and to the nodes (for user access to the applications).
The creation of the securitygroups probably does not need to be automated. The securitygroups will be created and the rulesets defined only once for a given OpenShift service. The web interface is probably appropriate for this.
Since we'll be creating the instances with the CLI, it will be necessary to be able to list, examine to apply the securitygroups to new instances there as well.
NOTE: These are not the security settings you are looking for.
The securitygroups and rulesets shown here are designed to demonstrate the securitygroup features and the user interface used to manage them. They are not designed with an eye to the best possible function and security for your service. You must look at your service design and requirements to create the best group and rulesets for your service.
Most people focus on the inbound (ingress) filtering rules. I'm going to go with that. I won't be defining any outbound (egress) rule sets.
I expect to need a different group for each type of host:
- OpenShift broker
- OpenShift node
- datastore
- message broker
- puppetmaster
In addition I'm going to manage the service hosts with Puppet using a puppetmaster host. Each of the service hosts will be a puppet client. I don't think the puppet agent needs any special rules so I only have one additional securitygroup.
If I also planned to use an external authentication service on the broker, I would need a securitygroup for that. I could also extend this set to include build and test servers for development of OpenShift itself.
Defining Securitygroups
Each of the groups below has only a single rule. To be rigorous I could add the SSH (22/TCP) rule to the node securitygroup. It is actually required for the operation of the node, not just for administrative remote access.
| securitygroup | service | port/proto | source | comments |
|---|---|---|---|---|
| default | SSH | 22/TCP | OpenShift Ops | remote access and control |
| puppetmaster | puppetmaster | 8140/TCP | all managed hosts | configuration management |
| datastore | mongodb | 27017/TCP | OpenShift Broker Hosts | NoSQL DB |
| messagebroker | activemq/stomp | 61613/TCP | OpenShift broke and node hosts | carries MCollective |
| broker | httpd (apache2) | 80/TCP, 443/TCP | OpenShift Ops and Users (unrestricted) | Ruby on Rails and Passenger |
| node | httpd (apache2) | 80/TCP, 443/TCP | OpenShift Application Users (unrestricted) | HTTP routing |
| Web Sockets | 8000/TCP, 8443/TCP | OpenShift App user | web sockets | |
| SSH | 22/TCP | OpenShift App Users (unrestricted) | shell and app control |
Populating each securitygroup is a two step process. First create the empty security group. Then add the rules to the group. At that point, the group is ready to be applied to new instances.
Creating a Securitygroup
Each security group starts with a name and an option description string. The restrictions on the names are different from EC2-Classic and EC2-VPC securitygroups. See the Amazon documentation for the differences. Simple upper/lower case strings with no white space are allowed in both. The descriptions are more freeform.
You can add new securitygroups on the AWS EC2 console page. Select the "Security Groups" tab on the left side and click "Create Security Group". Fill in the name and description fields, make sure that the VPC selector indicates "No VPC" and click "Yes, Create".
Adding Rulesets
Securitygroup rulesets are one of the more complex elements in EC2. When using the web interface, Amazon provides a set of pre-defined rules for things like HTTP and SSH and common database connections. You should use them when they're appropriate. The web interface also allows you to create custom rulesets.
There are several things to note about this display. The default group has three mandatory rules (blue and white bars in the lower right). These allow all of the members of the group unrestricted access to each other.
I'm adding the SSH rule which allows inbound port 22 connections. I'm leaving the source as the default 0.0.0.0/0. This is the IPv4 notation for "everything", so there will be no restrictions on the source of inbound SSH connections. If you want to restrict SSH access so that connections come only from your corporate network, you can set the exit address space for your company there.
Since the members of the default group have unrestricted access to each other and since I'm going to apply the default group to all of my instances, it turns out that I only need special rules for access to hosts from the outside. I need to add the SSH rule above, and I need to allow web access to the broker and node hosts. I am going to create these as distinct groups because I can't change the assigned groups for an instance after it is launched. I'd like the ability to restrict access to the broker later.
If I were to apply rigorous security to this setup, I would avoid using the default group. Instead I would create a distinct group for each service component. Then I would add rulesets which allow only the required communications. This would decrease the risk that a compromise of one host would grant access to the rest of the service hosts.
Since it's a one-time task, I created both of my securitygroups and rulesets using the web interface. I have written Thor tasks to create and populate securitygroups:
The list of tasks is incomplete, as I have not needed to change or delete rulesets. If I find that I need those tasks, I'll add them.
There are several things to note about this display. The default group has three mandatory rules (blue and white bars in the lower right). These allow all of the members of the group unrestricted access to each other.
I'm adding the SSH rule which allows inbound port 22 connections. I'm leaving the source as the default 0.0.0.0/0. This is the IPv4 notation for "everything", so there will be no restrictions on the source of inbound SSH connections. If you want to restrict SSH access so that connections come only from your corporate network, you can set the exit address space for your company there.
Since the members of the default group have unrestricted access to each other and since I'm going to apply the default group to all of my instances, it turns out that I only need special rules for access to hosts from the outside. I need to add the SSH rule above, and I need to allow web access to the broker and node hosts. I am going to create these as distinct groups because I can't change the assigned groups for an instance after it is launched. I'd like the ability to restrict access to the broker later.
If I were to apply rigorous security to this setup, I would avoid using the default group. Instead I would create a distinct group for each service component. Then I would add rulesets which allow only the required communications. This would decrease the risk that a compromise of one host would grant access to the rest of the service hosts.
Since it's a one-time task, I created both of my securitygroups and rulesets using the web interface. I have written Thor tasks to create and populate securitygroups:
thor help ec2:securitygroup Tasks: thor ec2:securitygroup:create NAME # create a new se... thor ec2:securitygroup:delete # delete the secu... thor ec2:securitygroup:help [TASK] # Describe availa... thor ec2:securitygroup:info # retrieve and re... thor ec2:securitygroup:list # list the availa... thor ec2:securitygroup:rule:add PROTOCOL PORTS [SOURCES] # add a permissio... thor ec2:securitygroup:rules # list the rules ... Options: [--verbose]
The list of tasks is incomplete, as I have not needed to change or delete rulesets. If I find that I need those tasks, I'll add them.
Next Up
This is everything that must be done before beginning to create running instances for my OpenShift service. In the next post I'll select a base image to use for my host instances and begin creating running machines.References
- AWS Network Security (securitygroups) http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html
No comments:
Post a Comment