Skip to main content

Creating firewalls using roles and tags

Even within a private network like Managed Nebula, it's a good idea to restrict the types of communication which can occur between different kinds of devices. For example, web server machines might need to communicate with database machines over certain ports, but they should not be able to ssh into user laptops. In Managed Nebula, these access rules are configured through firewall rules on roles and tags. This guide explains how roles and tags work together to manage both identity and access within a Managed Nebula network.

A role describes what a host is for, such as user-device, webserver, or database. Every host, lighthouse, and relay is assigned exactly one role when it's created. A tag is a key:value label describing some other facet of a host, like user-type:admin or region:us-west-1, and a host can carry as many tags as you need.

Firewall rules apply to inbound traffic, and you attach them to a role or to a tag. A rule on a role applies to every host with that role, and a rule on a tag applies to every host carrying that tag. Each rule specifies a protocol, an optional port range, and which hosts are allowed to connect, identified by their role, their tags, or both. A newly created role starts with a single rule allowing ICMP so that ping is available for troubleshooting; all other inbound traffic is denied until you add a rule to allow it.

Example scenario​

As an example, let's imagine you have an internal company webserver which serves a dashboard that only employees on the Managed Nebula network should be able to access. In addition, some employees, let's call them "admins", need to have SSH access to the webserver so they can perform maintenance on it. Let's take a look at how this can be accomplished using roles and tags.

Creating roles​

To create a role, visit the Roles page of your Defined Networking admin panel. Let's create a new webserver-internal role to use for web servers of an internal website. Start by clicking the Add button on the top right of the page and filling out the role name (required) and a description (optional). We will come back to this role and add firewall rules later, but for now we can click "Add role" to create it.

Add a new role form, requiring a name and an optional descriptionAdd a new role form, requiring a name and an optional description

We'll create another role for user-device as well, and we can see both new roles in the roles list page:

List of roles showing three roles: Lighthouse, user-device, and webserver-internalList of roles showing three roles: Lighthouse, user-device, and webserver-internal

Note that due to the way identity is securely managed, role names cannot be changed after they are created, but hosts can be edited to change their role. The firewall rules of roles can be changed at any time, and updates will be sent out to all affected machines automatically. Roles can be deleted so long as there are no hosts, lighthouses, or relays using the role.

Adding firewall rules​

By default, roles only have one firewall rule, to allow ping requests between them. Now let's open up TCP port 443 to allow https requests from employees so they can access the company dashboard. We'll click on webserver-internal to open that role's page, and then click the “Add firewall rule” button, then choose TCP for the protocol, type 443 as the port range, and select the user-device role from the Allowed role dropdown. We've entered a description as well, which is a good idea to help provide context for rules.

Inbound firewall rule form with a protocol choice, a port range, an allowed role, and an optional description.Inbound firewall rule form with a protocol choice, a port range, an allowed role, and an optional description.

Click the "Add rule" button to apply the change, but note that changes to roles are not saved until the “Save role” button is clicked, to minimize the number of updates sent to hosts on the network.

A Role details page with a couple of different firewall rules, and an enabled 'Save role' button that shows that you still need to save.A Role details page with a couple of different firewall rules, and an enabled 'Save role' button that shows that you still need to save.

Next we will see how to apply this role to hosts, and finally how to grant admin users SSH access to the webserver.

Applying roles to hosts​

Let's start by adding a web server host. Visit the Hosts page, and click the “Add” button. Choose a name, and click on the Role dropdown. Hosts (as well as lighthouses and relays) are only allowed to have one role.

Add a host form with an open 'select a role' dropdown hovering over `webserver-internal`Add a host form with an open 'select a role' dropdown hovering over `webserver-internal`

Similarly, we will create two user device hosts and give them both the appropriate user-device role.

Host list with three hosts: one webserver and two user devicesHost list with three hosts: one webserver and two user devices

The last thing we need to do is allow one of these users access to SSH into the webserver, which we will accomplish using tags.

Tags​

Tags can be thought of as attributes or slices of identity which can be applied to devices on your Managed Nebula network. They contain a key and a value, formatted as key:value. Each host can have multiple tags, and new tags can be created on-the-fly as you create or edit your hosts, or in the Tags page.

In our case, we can use a tag to indicate which employees should be considered admins, giving them SSH access to the webserver. Let's say that user-2 is an admin, and edit the user-2 host. Find the "Tags" field, and type user-type:admin.

Host edit form with new tag being created.Host edit form with new tag being created.

Tags can be defined and created on-the-fly when creating or editing hosts, as we are doing here. When a new tag will be created, it will be shown in green. When choosing an existing tag, it will be gray.

Tags field showing a green pill with the new tag's nameTags field showing a green pill with the new tag's name

Specifying tags in firewall rules​

Now that we have a new tag created for admins, we can create another firewall rule on the webserver-internal role to allow them access to SSH on TCP port 22, choosing the user-type:admin tag from the dropdown.

Form to add another firewall rule to the webserver-internal role, showing the 'user-type:admin' tag is chosen.Form to add another firewall rule to the webserver-internal role, showing the 'user-type:admin' tag is chosen.

After adding this rule and saving the role, only hosts with a role of user-device and a tag of user-type:admin will have SSH access. Note that the role and all tags in a rule must match before access is allowed (the conditions are "AND"ed together).

Configuring firewall rules on tags​

Every rule we've created so far lives on the webserver-internal role, so it protects each host that has that role. Because a host has exactly one role but can carry many tags, putting a rule on a tag instead lets you attach access policy to an attribute that cuts across roles, rather than repeating the same rule on every role that needs it. For example, an "allow SSH from user-type:admin" rule on a managed:true tag gives admins SSH access to every host you tag managed:true, whatever its role.

To add one, open a tag from the Tags page and add firewall rules the same way you did on the role. A host's inbound firewall is the union of the rules from its role and the rules from each tag it carries.

Conclusion​

By clearly defining the purpose of each type of machine on your network through the use of roles and assigning attributes of their identity using tags, it's possible to easily create targeted and effective firewall rules in your Managed Nebula network. If you have any questions or are having trouble setting up what you need, feel free to contact us for support.

On this page