Skip to main content

​
Access Control

NetBird implements a zero-trust security model with default deny behavior. This means that no peer can communicate with another peer unless explicitly allowed by an access policy.

​
Default Deny Architecture

Unlike traditional VPNs that grant broad network access, NetBird follows a zero-trust approach:
  • No implicit trust: Peers joining the network have no automatic access to other peers
  • Explicit allow rules: Communication is only permitted through defined policies
  • Granular control: Access can be scoped to specific groups, protocols, and ports
  • Bidirectional rules: Policies can control traffic flow in one or both directions
When you first create a NetBird account, a default policy is automatically created that allows all peers to communicate. You can disable or delete this policy to enforce stricter access controls.

​
Access Control Components

NetBird’s access control system is built on three main components:

​
1. Groups

Groups organize peers and users into logical collections. They serve as the building blocks for policies.
  • Peer Groups: Collections of network devices
  • User Groups: Collections of users (for SSH access control)
  • Dynamic Groups: Auto-populated based on setup keys or identity provider attributes
Learn more in the Groups documentation.

​
2. Policies

Policies define the access rules between groups. Each policy contains one or more rules that specify:
  • Source groups (who initiates the connection)
  • Destination groups (who receives the connection)
  • Allowed protocols and ports
  • Traffic direction (unidirectional or bidirectional)
Learn more in the Policies documentation.

​
3. Posture Checks

Posture checks ensure devices meet security requirements before granting access:
  • Operating system version checks
  • Geolocation requirements
  • Custom validation scripts
Posture checks are attached to policies as source requirements.

​
Network Connectivity Flow

Here’s how NetBird determines if two peers can communicate:
1
Check Policy Status
2
The system first checks if there are any enabled policies that reference the source and destination peers.
3
Evaluate Group Membership
4
Both peers must be members of groups referenced in at least one policy rule.
5
Validate Posture Checks
6
If the policy has source posture checks defined, the source peer must pass all required checks.
7
Apply Protocol and Port Filters
8
The connection must match the protocol (TCP, UDP, ICMP, or ALL) and port specifications in the policy rule.
9
Check Traffic Direction
10
The policy rule must permit traffic in the requested direction (direct or bidirectional).

​
Access Control Best Practices

Disable or delete the default “Allow All” policy and build access rules based on the principle of least privilege. Only grant the minimum access necessary for peers to perform their functions.
Name groups based on their function, location, or department (e.g., production-servers, dev-team, office-london). This makes policies easier to understand and maintain.
Attach posture checks to policies for sensitive resources. For example, require the latest OS version for peers accessing production databases.
Use the policy description field to explain why the policy exists and what business need it serves. This helps during security audits and policy reviews.
Periodically review group memberships and policies to ensure they still reflect current access requirements. Remove unnecessary access promptly.

​
Access Control vs. Traditional Firewalls

Traditional FirewallNetBird Access Control
Network-based (IP addresses)Identity-based (groups)
Static rulesDynamic, follows peers
Perimeter securityZero-trust model
Broad access zonesGranular peer-to-peer
Manual IP managementAutomatic peer discovery

​
Common Access Control Patterns

​
Hub-and-Spoke Access

Allow remote workers to access specific servers: 
Policy: Remote Access to Services
Source: remote-workers (group)
Destination: app-servers (group)
Protocol: TCP/443, TCP/22
Direction: Unidirectional

​
Segmented Environments

Isolate production from development: 
Policy 1: Dev Environment Access
Source: dev-team (group)
Destination: dev-servers (group)
Protocol: ALL
Direction: Bidirectional

Policy 2: Production Access (no dev access)
Source: ops-team (group)
Destination: prod-servers (group)
Protocol: TCP/443, TCP/22
Direction: Unidirectional

​
Department Isolation

Allow peers within a department to communicate freely: 
Policy: Engineering Internal
Source: engineering-dept (group)
Destination: engineering-dept (group)
Protocol: ALL
Direction: Bidirectional

​
Activity Logging

NetBird logs all access control changes for audit purposes:
  • Policy creation, modification, and deletion
  • Group membership changes
  • Posture check results
  • Access denial events
These logs are available through the NetBird dashboard and API for security monitoring and compliance reporting.
Changes to policies and groups take effect immediately. Before modifying production access rules, verify group memberships and test changes in a non-production environment when possible.
  • Groups - Organize peers and users
  • Policies - Define access rules
  • Routes - Access external networks
  • DNS - Private DNS resolution

Build docs developers (and LLMs) love

Get started for freeTalk to us