DigitalOcean Cloud Firewalls provide a central location for preventing unauthorized traffic from reaching your Droplets that is easy to configure, quick to apply, and automation-friendly. Still, organizing the infrastructure can be tricky.
On the one hand, if you start to create Firewalls without a plan, you can end up with dozens of Firewalls that don’t make a lot of sense. On the other hand, over-complicated planning can lead to analysis paralysis.
In this article, we’ll explore an initial strategy for organizing your Cloud Firewalls that will make them easier to use and maintain as well as document the relationships within your infrastructure.
To get started, we’ll build our Cloud Firewalls based on the roles their rules serve. For example, if we have a monolithic web application, say a Droplet named
website running a PHP application with a local MySQL database, there are two distinct roles that need to be fulfilled:
We could have a single Cloud Firewall with rules to allow both jobs, and for small deployments it would work fine. However, if we’re expecting it to scale the app in the future, we can separate these concerns now and create two different Firewalls:
webserver-fw: Opens TCP ports 80 (if we allow unencrypted traffic) and 443 (if we are using SSL) to all sources.
management-fw: Opens TCP port 22 (SSH) to all sources. If we want to restrict the access to specific locations such an IP range in our office, we would add that in the sources of this rule as well.
Separating the Firewalls in this way indicates which access is for administrators and which is for end user interaction. The names help document the system, which is especially useful when someone less familiar with its details needs to step in. It becomes even more useful as our infrastructure becomes more complex.
As the application grows, we might want to split workloads across multiple servers. It’s common, for example, to separate the web server and database, putting each one on its own Droplet. When we make a change like that, we can adapt our Firewall strategy as follows:
management-fwwithout any changes. We’ll still need to use SSH for administrative tasks.
webserver-fwas-is. Its functionality is still the same.
database-fw, with a rule to open TCP port 3306 — MySQL’s default — to the source Droplet
management-fwto the new Droplet. Administrators will be able to do their work, and only the
websiteserver will be allowed to access the database port.
Our initial organization allowed us to avoid changes to previously created Cloud Firewalls, reuse one of them, clearly indicate the service being used on the new
database Droplet, and open access to each server by adding what is strictly required.
So far we’ve talked about a small application which can be served by one or two Droplets, and we’ve applied the firewalls by using the Droplet names. When our traffic grows and we prepare to scale up, using Droplet names can become unwieldy.
We might choose to keep our two-server architecture and scale vertically by beefing up the servers with more memory or processing power so they can keep up with requests, but this won’t change the fact that each one is still a single point of failure. Because we’re working in the Cloud, we’re more likely to scale horizontally, where we distribute traffic among multiple redundant servers. At this point, we’ll need to start using tools and practices that allow us to treat Droplets as interchangeable resources. This shift in strategy is known in Cloud circles as “Pets vs Cattle” and goes hand-in-hand with configuration management tools like Ansible, Chef, and Puppet.
When we start to think of our Droplets as groups of redundant, interchangeable resources, we need group-based ways to work with them. DigitalOcean facilitates group-based management using tags, which are text labels that we attach to Droplets to classify them. Once we’ve tagged Droplets, we use those tags to create relationships between other DigitalOcean resources like load balancers and Cloud Firewalls.
In our case, we can create two tags,
database, and add the appropriate tag to each Droplet. When we do this, we’ll also rename the Droplets to
database-01, explicitly marking them as replaceable pieces of our deployment. Then, we will change our Cloud Firewalls as follows:
management-fw: Add both
databasetags to them and remove the association with specific Droplet names.
webserver-fw: Add the
webservertag and remove the
database-fw: Add the
databasetag and remove the
database-01Droplet. Change the source on the TCP 3306 rule from the named Droplet to use the tag
With this shift to tags, each Cloud Firewall’s rules will be applied to any Droplet marked with those tags. It doesn’t matter how many Droplets there are. If we were to launch a couple of new webserver Droplets, like
website-03, they would automatically get the rules from
webserver-fw and be granted access to any Droplet where the
database-fw is applied. This lets us focus on scaling the application up or down while the security controls are handled by Cloud Firewalls.
The process above could be extended to more complex applications. For example, if we had a subsystem to queue requests or a group of servers dedicated as process workers, we could tag them as
workers respectively, apply the Firewall rules that are specific to them, and share common aspects like
Using tags to organize and document our infrastructure clarifies relationships between different Droplets and makes it easier to manage them in bulk. We are not restricted to a single tag per Droplet, so we can apply other tags to help automate or document processes.
management as generic examples of Cloud Firewall names. You should use names that make sense for you and your team’s specific context. Perhaps
deployment would be more appropriate than
management. If that’s the case, use
We’re also adding
-fw to the end of the Firewall names to identify resources in situations where there isn’t a UI to distinguish items. Suppose, for example, you have a Droplet named
webserver with a
webserver tag and a Firewall named
webserver. When you parse the output of a command-line tool like doctl, which is which? In the control panel UI it’s usually indicated, but this may not be the case in other scenarios, so using a naming strategy to differentiate can add clarity and simplify scripting.