Creating Firewalls Using Roles
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. These access rules are managed through the use of roles. This guide will explain what roles are and how they are used to manage both identity and access within a Managed Nebula network.
In Managed Nebula, a role represents the primary purpose and group-identity of a host. For example, you might create
roles such as Admin Endpoint, User Endpoint, WWW Server, etc. Each machine that you create should be assigned a role
when it is created. Firewall rules are configured for inbound traffic at the role level. Newly created roles allow only
ICMP traffic so that ping requests can be used for troubleshooting. All other inbound traffic is denied by default,
and the rules can be configured to allow other kinds of traffic from machines belonging to specific roles.
Note that currently, due to the way identity is securely managed, role names cannot be changed after they are created, and hosts cannot 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.
To create a role, visit the Roles page of your Defined Networking admin panel. A
default “Lighthouse” role was created automatically when your account was provisioned. Let's create a new www-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'll create two more roles for endpoint-employee and endpoint-admin. We can see that they have been added to the
list of roles, and that they all have one rule.
Let's click on www-internal to open that role's page.
Now, we want to allow inbound TCP traffic on port 443 from both kinds of endpoints, so that HTTPS requests to the internal page from administrators and employees are allowed. First, click the “Add firewall rule” button, then choose TCP for the protocol, type 443 as the port range, and select the endpoint-employee role from the Allowed role dropdown. We've entered a description as well, which is a good idea to help provide context for rules.
We'll add the same rule for endpoint-admin so they can access the website, as well as one final rule to allow TCP:22
for admins, so that they can also ssh into web server boxes. The final result looks like this:
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.
After saving, let's add 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.
Note, that it's also possible to create new roles along with the host, by choosing the “Add new role” option. Roles added this way will only allow ICMP traffic, but the firewall rules can be edited as shown above.
Roles can be deleted so long as there are no hosts, lighthouses, or relays using the role. To delete a role, choose the “Delete role” option from the role's three-dot menu on the Roles page, and then confirm your decision in the confirmation dialog.
