Control your WireGuard-based network access in just a few clicks with NetBird.
We are happy to announce the release of the NetBird Access Control feature! Those who prefer reading code instead of text are welcome to our GitHub repo :) Don't forget to leave a ⭐
If you are using NetBird, you might have noticed a new
Access Control tab in the management Web UI. This is where the
network access management magic happens.
What are the NetBird access controls?
As the name stands, access controls help to manage access in your network. Every machine in the network (or a peer in NetBird's terms) is a resource you might want to allow or restrict access to. In the previous NetBird versions, peers formed a full mesh where everyone could connect to anything. Such behavior might be desired in small networks with just a few machines, for example, when you want to automate your home network and connect to a bunch of Raspberry PIs or a NAS server remotely. In this case, having a full mesh shouldn't be a big deal. But what if you are managing an organization's network with dozens or hundreds of machines and employees? That is a different story, where a granular access control becomes more relevant. You don't want everybody and every machine to access your critical infrastructure or production database.
We have designed a simple tagging system that allows you to create peer groups and define access rules specifying what groups can communicate with each other. All done in just a few clicks from the Web UI.
To give you a grasp of how it works, let's consider the following example. You have a team of 10 engineers using NetBird
installed on their laptops to connect to the network and a set of servers in the cloud running different applications, services, containers, and databases.
The first idea you might have is to group engineers allowing access to the group of servers.
Team tag and assign it to every team member's peer. The second group named
Servers tags all the server machines.
You can easily create new tags and tag peers in the
Peers tab in the Web UI.
You can then switch to the Access Control tab and
Add New Rule, providing the
Team tag as a source and
Servers as a destination.
After saving the changes, the peers of these two groups can communicate. However, peers from the
Team group won't be able to connect with each other.
The same applies to servers. You can change this behavior by creating a new rule specifying the same tag for both source and destination.
You can create tags with just a single peer, thus allowing for very granular access controls on a single resource level.
What is next?
We are working on further improvements to access controls that include:
- Rule directions. Define the direction of the connection. E.g., allow one side to access the other but not another way around.
- More granular access controls that work on a port level. E.g., allow only port 80.
- Application-level access control. E.g., pick a list of running applications like SSH or internal services (Jira, GitLab).