mirror of
https://github.com/netbirdio/docs.git
synced 2026-04-20 17:36:36 +00:00
New Group and Access Policies Document and Initial Reorganization of Access Control Structure (#477)
* New Access Control and ReOrg * Enhance Access Control Documentation and Add New Resources - Updated `next.config.mjs` to include new redirects for access control documentation. - Added multiple images related to access control and endpoint detection and response. - Refactored links in various documentation files to point to the new access control structure. - Removed outdated documentation files and created new ones for managing access control and endpoint detection. - Introduced a new section for understanding posture checks and their implementation in access control. This commit aims to improve the organization and clarity of access control resources, aligning with the recent restructuring of documentation. * Remove outdated Intune MDM documentation and update links in access control resources. This commit enhances the organization of the documentation by eliminating obsolete files and ensuring all references to Microsoft Intune are correctly aligned with the new structure. * Fix typos in access control documentation for clarity and accuracy. Updated "Understnading" to "Understanding" and corrected "NerBird" to "NetBird" in relevant sections. * Fix typo in Access Control section * Fix formatting in posture checks documentation * Added a space in the Posture Checks reference for clarity.
This commit is contained in:
Brandon Hopkins
@@ -0,0 +1,88 @@
|
||||
# Restrict Network Access with CrowdStrike Falcon®
|
||||
|
||||
[CrowdStrike Falcon](https://www.crowdstrike.com/platform/) is a cloud-based endpoint protection platform that provides
|
||||
comprehensive visibility and threat detection capabilities. CrowdStrike Falcon agent runs on your devices (endpoints),
|
||||
collects, and analyzes endpoint data to detect and respond to threats in real-time. The agent's presence on endpoints and data
|
||||
it collects can be utilized to enforce access policies and limit network access according to the "health" status of the
|
||||
endpoints.
|
||||
|
||||
The integration of NetBird with CrowdStrike Falcon provides organizations with network security controls that allow
|
||||
only IT-managed devices running CrowdStrike to access the network. Additionally, the integration uses [CrowdStrike's Zero Trust Assessment (ZTA) score](https://www.crowdstrike.com/press-releases/crowdstrike-extends-zero-trust-to-endpoint-devices/),
|
||||
enabling administrators to further limit network access based on the security posture of each device.
|
||||
|
||||
CrowdStrike's Zero Trust Assessment (ZTA) score is a numerical representation of the security posture of a device with
|
||||
a value ranging from 0 to 100. The score is calculated based on various factors, including the device's security configuration,
|
||||
software vulnerabilities, and CrowdStrike's threat intelligence data. By integrating with CrowdStrike Falcon,
|
||||
NetBird can ensure that only devices with a high security posture can access the network.
|
||||
|
||||
In this guide, we will walk you through the configuration steps to integrate CrowdStrike Falcon with NetBird and use ZTA score
|
||||
to allow network access to devices that meet a specified ZTA threshold.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before you start creating and configuring a CrowdStrike integration, ensure that you have the following:
|
||||
- A CrowdStrike account with the permissions to create and manage API keys.
|
||||
If you don't have the required permissions, ask your CrowdStrike administrator to grant them to you.
|
||||
|
||||
## Create a CrowdStrike API Key
|
||||
|
||||
- Navigate to the [API clients and keys](https://falcon.eu-1.crowdstrike.com/api-clients-and-keys/) page
|
||||
- Click `Create API client` at the top, right corner
|
||||
- Set Hosts - Read permission
|
||||
- Set Zero Trust Assessment - Read permission
|
||||
- Click `Create`
|
||||
- Copy the credentials. You will need these credentials when configuring an integration in NetBird.
|
||||
|
||||
## Configure a CrowdStrike Integration in NetBird
|
||||
|
||||
- Navigate to the [Integrations » EDR](https://app.netbird.io/integrations?tab=edr) tab in the NetBird dashboard
|
||||
- Click `Connect CrowdStrike` to start the configuration wizard
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/endpoint-detection-and-response/crowdstrike-edr/crowdstrike-integration.png" alt="event-streaming-integration" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
- First, select the region of your CrowdStrike account
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/endpoint-detection-and-response/crowdstrike-edr/crowdstrike-region.png" alt="crowdstrike-region" className="imagewrapper"/>
|
||||
</p>
|
||||
- Then enter the client ID and secret key you created in [Step 1](#step-1-create-a-crowd-strike-api-key) and click `Continue`
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/endpoint-detection-and-response/crowdstrike-edr/crowdstrike-credentials.png" alt="crowdstrike-credentials" className="imagewrapper"/>
|
||||
</p>
|
||||
- Select groups you want to apply the integration to
|
||||
- If you would like to apply a ZTA threshold, then enable the [Zero Trust Assessment Score](https://www.crowdstrike.com/blog/tech-center/securing-private-applications-with-crowdstrike-zero-trust-assessment-and-aws-verified-access/) and set the desired limit, and click `Connect`.
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/endpoint-detection-and-response/crowdstrike-edr/crowdstrike-groups-zta.png" alt="crowdstrike-groups-zta" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
<Note>
|
||||
The EDR check will apply only to machines in the selected groups and will require a running CrowdStrike agent.
|
||||
</Note>
|
||||
<Note>
|
||||
You can also use groups [synchronized from your Identity Provider (IdP)](/how-to/idp-sync).
|
||||
</Note>
|
||||
|
||||
- Peers that have the CrowdStrike agent installed will be granted access to the network. Peers without the agent will appear
|
||||
with a `Approval required` mark in the peers list and won't be able to access the network until the agent is installed.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/endpoint-detection-and-response/crowdstrike-edr/edr-approval-required.png" alt="edr-approval-required" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
- Optional. You can experiment and see how the integration works by hiding hosts in the CrowdStrike Host management console:
|
||||
- Navigate to the [Host management](https://falcon.crowdstrike.com/host-management/hosts) page in the CrowdStrike console
|
||||
- Select a host you want to hide
|
||||
- Click `Actions` and then `Hide`
|
||||
- The host will be moved to Trash (you can restore it later)
|
||||
- After about a minute, the peer will be disconnected from the network and marked as `Approval required` in the NetBird dashboard.
|
||||
- To restore the host in CrowdStrike, navigate to the Trash and click `Restore`
|
||||
|
||||
<Note>
|
||||
NetBird synchronizes the list of devices managed by the EDR platform via the API about every minute.
|
||||
The changes might not be visible immediately.
|
||||
</Note>
|
||||
|
||||
<Note>
|
||||
If you install the CrowdStrike agent on a peer after it joined the network, you will need to disconnect and reconnect
|
||||
this peer for the `Approval required` mark to disappear.
|
||||
</Note>
|
||||
@@ -0,0 +1,40 @@
|
||||
# Integrate NetBird with MDM & EDR Platforms
|
||||
|
||||
|
||||
|
||||
## What is EDR and MDM?
|
||||
Endpoint Detection and Response (EDR) is a cybersecurity technology designed to help organizations detect, investigate,
|
||||
and respond to threats on endpoint devices. An endpoint is any device that is connected to a network, such as laptops,
|
||||
desktops, smartphones, tablets, servers, and even some IoT (Internet of Things) devices.
|
||||
|
||||
MDM stands for Mobile Device Management. It's a type of security software that
|
||||
enables organizations to monitor, manage, and secure their employees' mobile devices, including smartphones, tablets, and laptops,
|
||||
across various service providers and operating system.
|
||||
|
||||
MDM focuses on managing and securing mobile devices, while EDR focuses on detecting and responding to threats on various
|
||||
endpoints, including desktops, laptops, and servers.
|
||||
|
||||
## NetBird's EDR and MDM Integration
|
||||
With the rise of remote work, endpoints often operate outside the traditional corporate network perimeter,
|
||||
making them more vulnerable to attacks. EDR provides a layer of security that is not dependent on the physical location
|
||||
of the endpoint, thus extending protection to remote workers and their devices.
|
||||
|
||||
NetBird integrates with major EDR and MDM platforms to restrict network access only to devices managed by the company's IT department.
|
||||
With the integration enabled, NetBird synchronizes the list of devices managed by the MDM or EDR platform via the API and
|
||||
checks the presence of the MDM or EDR agent on the device, blocking access to the network if the agent is not installed or
|
||||
not compliant with the organization's security policies.
|
||||
|
||||
NetBird doesn't apply the MDM and EDR checks to all devices in the network. Instead, you can select specific groups of devices for
|
||||
the checks to apply.
|
||||
|
||||
<Note>
|
||||
This feature is only available in the cloud version of NetBird.
|
||||
</Note>
|
||||
|
||||
## Supported EDR Platforms
|
||||
|
||||
NetBird integrates with the following EDR platforms:
|
||||
|
||||
* [CrowdStrike Falcon](/manage/access-control/endpoint-detection-and-response/crowdstrike-edr)
|
||||
* [Microsoft Intune](/manage/access-control/endpoint-detection-and-response/intune-mdm)
|
||||
* [SentinelOne Singularity](/manage/access-control/endpoint-detection-and-response/sentinelone-edr)
|
||||
@@ -0,0 +1,167 @@
|
||||
# Allow Only Intune-Managed Devices to Access Your Network
|
||||
|
||||
<div className="videowrapper">
|
||||
<iframe src="https://www.youtube.com/embed/W4DaE4Dj04o" allow="fullscreen;"></iframe>
|
||||
</div>
|
||||
|
||||
<Note>
|
||||
TLDR: Devices marked as "Non-compliant" in Intune will automatically lose access, ensuring strict adherence to your security policies.
|
||||
Once a device returns to a "Compliant" status, access is restored.
|
||||
</Note>
|
||||
|
||||
[Microsoft Intune](https://www.microsoft.com/en-us/security/business/endpoint-management/microsoft-intune) is a cloud-based endpoint management platform that enables organizations to manage devices, enforce security policies, and protect their networks. Intune agent presence on endpoints allows continuous collection and evaluation of device posture, which can then be used to enforce network access controls based on device compliance, security configuration, and enrollment status.
|
||||
|
||||
The integration of NetBird with Microsoft Intune provides network security by ensuring only devices managed and compliant
|
||||
in Intune can access the protected network. This approach ensures only up-to-date and compliant Windows/macOS endpoints have access to critical network resources via NetBird and lets administrators enforce access restrictions based on compliance policies defined in Intune, such as device health, OS version, security baseline adherence, and more.
|
||||
|
||||
In this guide, you'll learn how to integrate NetBird with Microsoft Intune and configure access controls to allow only Intune-managed/compliant devices onto your network.
|
||||
|
||||
## Get Started with NetBird-Intune Integration
|
||||
|
||||
- Navigate to the [Integrations » EDR](https://app.netbird.io/integrations?tab=edr) tab in the NetBird dashboard
|
||||
- Click `Connect Intune` to start the configuration wizard
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/getting-started.png" alt="NetBird Get Started Intune MDM" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before starting the integration process, verify that you have the required permissions in Microsoft Intune.
|
||||
Specifically, you will need an Azure user account with at least one of these roles:
|
||||
|
||||
* Application Administrator
|
||||
* Cloud Application Administrator
|
||||
* Global Administrator
|
||||
|
||||
To check your permissions:
|
||||
|
||||
* Log in to the [Azure portal](portal.azure.com).
|
||||
* Navigate to Manage Microsoft Intune and click `View`.
|
||||
* Expand the `Manage` tab and click on `Roles and administrators` in the left menu.
|
||||
* Look for your username and verify if you're assigned any of the above roles.
|
||||
|
||||
|
||||
|
||||
If you don't have the required permissions, contact your Azure AD administrator to grant you the appropriate role before proceeding with the NetBird integration.
|
||||
|
||||
## Create and Configure a Microsoft Entra ID Application for NetBird Integration
|
||||
|
||||
Now that you have the required permissions, return to the NetBird dashboard. Click on the `Get Started` button to initiate the integration process.
|
||||
|
||||
A new wizard screen will appear, offering step-by-step instructions for creating and configuring your Microsoft Entra ID application. To simplify the process, the wizard also provides quick-copy buttons for essential information:
|
||||
|
||||
* Name
|
||||
* Account Type
|
||||
|
||||
|
||||
|
||||
For convenience, click on [Azure Active Directory](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Overview) (step 1). That will open the Azure dashboard. Navigate to `App registrations` in the left menu and then click `+New registration` as indicated below:
|
||||
|
||||
|
||||
|
||||
Fill in the required information:
|
||||
|
||||
|
||||
|
||||
After entering all required information, click the `Register` button at the bottom of the form to finalize the application registration process.
|
||||
|
||||
Upon successful registration, you'll be redirected to a confirmation screen similar to the following:
|
||||
|
||||
|
||||
|
||||
Copy and securely store the generated `Application (client) ID` and `Directory (tenant) ID` as you will need them shortly.
|
||||
|
||||
## Configure API Permissions for NetBird-Intune Integration
|
||||
|
||||
On the NetBird dashboard click the `Continue →` button. A new wizard screen will appear, this time, offering step-by-step instructions for setting up API permissions.
|
||||
|
||||
|
||||
|
||||
Back to Azure, in the `App registrations` screen, click on `Manage` in the left menu to expand it and then click on `API permissions`:
|
||||
|
||||
|
||||
|
||||
Look for the `+ Add a permission` button, located near the top of the permissions list and click on it.
|
||||
|
||||
|
||||
|
||||
A new pop-up window will appear, asking you to select an API. Click on `Microsoft Graph`.
|
||||
|
||||
|
||||
|
||||
On the next screen, click on the `Application permissions` button, which will let you select the appropriate permissions for NetBird to function correctly with your Microsoft Intune environment.
|
||||
|
||||
|
||||
|
||||
To assign user permissions:
|
||||
|
||||
* Locate the search bar at the top. Type `DeviceManagementManagedDevices.Read.All` into the search bar and press `Enter`.
|
||||
* In the search results, click on the `DeviceManagementManagedDevices` tab to expand it and view the available permissions.
|
||||
* Click on the checkbox to select and enable the `DeviceManagementManagedDevices.Read.All` permission.
|
||||
|
||||
|
||||
|
||||
The `DeviceManagementManagedDevices.Read.All` permission allows NetBird to read the properties of all devices managed by Microsoft Intune in your organization.
|
||||
|
||||
Once done, click the `Add permissions` button. You will see a few warnings:
|
||||
|
||||
|
||||
|
||||
Locate the `Grant admin consent for [Your Organization Name]` button (you’ll find it next to `+Add a permission` button). Click on it to grant the required permissions.
|
||||
|
||||
A confirmation dialog will appear, asking you to verify this action. Review the permissions listed in the dialog and click `Yes` to confirm. Wait for the process to complete, this may take a few seconds.
|
||||
|
||||
Once finished, the status of the permissions should change to `Granted for [Your Organization Name]`. Verify that all selected permissions now show a green checkmark, indicating they've been successfully granted:
|
||||
|
||||
|
||||
|
||||
## Create a Client Secret for Secure NetBird-Intune Authentication
|
||||
|
||||
Back to the NetBird dashboard, click the `Continue →` button. A new wizard screen will appear, showing instructions for generating a client secret in Entra ID.
|
||||
|
||||
|
||||
|
||||
On Azure, click on the `Certificates & secrets` button in the left menu to open the management page. Click on `+New client secret` as shown below. Choose an expiration time that suits your security needs and click the `Add` button.
|
||||
|
||||
|
||||
|
||||
A new client secret will be generated and displayed on the screen. Copy and securely store the `Value` field immediately, as you will needed in the next step.
|
||||
|
||||
|
||||
|
||||
## Enter Application ID and Directory ID in NetBird
|
||||
|
||||
Paste the secret `Value` from the previous step into NetBird and click the `Continue →` button. A new wizard screen will appear, asking for the `Application (client) ID` and the `Directory (tenant) ID` credentials generated previously.
|
||||
|
||||
Paste the values and click the `Continue →` button.
|
||||
|
||||
|
||||
|
||||
## Choose Groups to require Intune Agent
|
||||
|
||||
At this stage, specify one or more NetBird groups to which the check should apply. The check will require the peer to have a running Intune agent installed.
|
||||
|
||||
|
||||
|
||||
|
||||
<Note>
|
||||
The MDM check will apply only to machines in the selected groups and will require a running Intune agent.
|
||||
</Note>
|
||||
<Note>
|
||||
You can also use groups [synchronized from your Identity Provider (IdP)](/how-to/idp-sync).
|
||||
</Note>
|
||||
|
||||
Peers that have the Intune agent installed and are compliant will be granted access to the network. Peers without the agent will appear
|
||||
with a `Approval required` mark in the peers list and won't be able to access the network until the agent is installed.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/edr-approval-required.png" alt="edr-approval-required" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
## Important Notes
|
||||
|
||||
- Only Windows and macOS devices are supported; Linux, iOS, and Android are not eligible for this integration.
|
||||
- A device must have successfully synced with Intune within the last 24 hours otherwise, it will not be treated as compliant, regardless of its last known state.
|
||||
- Devices with a Intune compliance state of `Compliant` or `InGracePeriod` are accepted; all other states are rejected.
|
||||
- New devices or those that recently achieved compliance may need to be disconnected and reconnected to NetBird to propagate updated status.
|
||||
- NetBird regularly synchronizes with Intune every few minutes, so changes in compliance can take some time to reflect on the dashboard.
|
||||
@@ -0,0 +1,114 @@
|
||||
# Restrict Network Access with SentinelOne Singularity™
|
||||
|
||||
[SentinelOne Singularity](https://www.sentinelone.com/platform/) is an autonomous cybersecurity platform that provides
|
||||
comprehensive endpoint protection, detection, and response capabilities. The SentinelOne agent runs on your devices (endpoints),
|
||||
collecting and analyzing endpoint data to detect and respond to threats in real-time. The agent's presence on endpoints and the
|
||||
security data it collects can be utilized to enforce access policies and limit network access according to the "health" status
|
||||
of the endpoints.
|
||||
|
||||
The integration of NetBird with SentinelOne provides organizations with robust security controls that allow
|
||||
only IT-managed devices running SentinelOne to access the network. Additionally, the integration uses SentinelOne's threat
|
||||
detection capabilities, enabling administrators to further limit network access based on the security posture of each device.
|
||||
|
||||
<div className="videowrapper">
|
||||
<iframe src="https://www.youtube.com/embed/QVs0RhprVYM" allow="fullscreen;"></iframe>
|
||||
</div>
|
||||
|
||||
SentinelOne's endpoint protection provides real-time threat detection and automated response capabilities. By integrating with
|
||||
SentinelOne Singularity, NetBird can ensure that only devices with active security monitoring and protection can access the network.
|
||||
|
||||
In this guide, we will walk you through the configuration steps to integrate SentinelOne Singularity with NetBird and use
|
||||
endpoint security status to control network access for devices that meet your security requirements.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before you start creating and configuring a SentinelOne integration, ensure that you have the following:
|
||||
- A SentinelOne account with the permissions to create and manage API tokens.
|
||||
If you don't have the required permissions, ask your SentinelOne administrator to grant them to you.
|
||||
|
||||
## Create a SentinelOne API Token
|
||||
|
||||
- Navigate to your SentinelOne Management Console
|
||||
- Go to **Settings** » **Users** » **Service Users**
|
||||
- Click **Create Service User**
|
||||
- Fill in the form:
|
||||
- **Name**: `NetBird Integration`
|
||||
- **Description**: `API token for NetBird EDR integration` (optional)
|
||||
- **Expiration Date**: Set your preferred expiration date
|
||||
- Click **Next**
|
||||
- Select Site and set **Scope** to **Viewer**
|
||||
- Click **Create User**
|
||||
- Copy the generated API token immediately (it will only be displayed once)
|
||||
- Note your SentinelOne console URL from your browser's address bar (e.g., `https://your-tenant.sentinelone.net`)
|
||||
|
||||
<Note>
|
||||
Treat the API token securely and store it safely. You will need both the console URL and API token for the NetBird integration configuration.
|
||||
</Note>
|
||||
|
||||
## Configure a SentinelOne Integration in NetBird
|
||||
|
||||
- Navigate to the [Integrations » EDR](https://app.netbird.io/integrations?tab=edr) tab in the NetBird dashboard
|
||||
- Click **Connect SentinelOne** to start the configuration wizard
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/endpoint-detection-and-response/sentinelone/getting-started.png" alt="SentinelOne integration getting started" className="imagewrapper-big"/>
|
||||
</p>
|
||||
- Click the **Get Started** button to initiate the integration process
|
||||
- Enter your SentinelOne console URL (e.g., `https://your-tenant.sentinelone.net`) and click **Continue**
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/endpoint-detection-and-response/sentinelone/console-config.png" alt="SentinelOne console configuration" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
- Enter the API token you created in the previous step and click **Continue** to verify the connection
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/endpoint-detection-and-response/sentinelone/service-user.png" alt="SentinelOne service user configuration" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
- Select the **groups** you want to apply the integration to and click **Connect**
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/endpoint-detection-and-response/sentinelone/group-config.png" alt="SentinelOne group configuration" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
|
||||
<Note>
|
||||
The EDR check will apply only to peers in the selected groups and will require a running SentinelOne agent.
|
||||
You can also use groups [synchronized from your Identity Provider (IdP)](/how-to/idp-sync).
|
||||
</Note>
|
||||
|
||||
- Configure the compliance criteria that devices must meet to access your network. These security requirements ensure only healthy, properly configured devices can connect. Select the criteria that align with your organization's security policies:
|
||||
- **Allowed Active Threats**: Maximum number of active threats allowed on a device. Default is set to `0` to block devices with any active threats.
|
||||
- **Disk Encryption**: Requires disk encryption to be enabled on the device.
|
||||
- **Firewall**: Requires the device firewall to be enabled and active.
|
||||
- **Block Infected Devices**: Prevents network access for devices with confirmed active infections.
|
||||
- **Network Connectivity**: Requires active network connection between the device and SentinelOne services.
|
||||
- **Active Status**: Requires the SentinelOne agent to be active and reporting. The agent must be in operational state (not disabled, corrupted, or experiencing errors).
|
||||
- **Latest Agent Version**: Requires the SentinelOne agent to be running the most current version.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/endpoint-detection-and-response/sentinelone/compliance-config.png" alt="edr-integrations" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
|
||||
- Configure the **SentinelOne Sync Window** (default is 24 hours). This setting determines which devices NetBird will consider for network access based on their recent activity in SentinelOne. Only devices that have been active and reporting to SentinelOne within this time window will be synchronized. These devices must then also meet the configured compliance criteria to gain network access.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/endpoint-detection-and-response/sentinelone/sync-config.png" alt="edr-integrations" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
- Click **Connect** to complete the integration setup
|
||||
|
||||
- Only peers that have the SentinelOne agent installed and meet all the configured compliance criteria will be granted access to the network.
|
||||
Peers without the SentinelOne agent or those that don't meet the compliance requirements will appear with an `Approval required` mark in the peers list and won't be able to access
|
||||
the network until they have the agent installed and satisfy all the specified security requirements.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/endpoint-detection-and-response/sentinelone/edr-approval-required.png" alt="edr-approval-required" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
|
||||
<Note>
|
||||
NetBird matches the SentinelOne agent to the peer using the Serial Number of the device. You must ensure that each of your devices has a unique serial number.
|
||||
</Note>
|
||||
|
||||
432
src/pages/manage/access-control/index.mdx
Normal file
432
src/pages/manage/access-control/index.mdx
Normal file
@@ -0,0 +1,432 @@
|
||||
# Understanding Groups and Access Policies
|
||||
NetBird's access control system is built on Zero Trust security principles, ensuring that no device or user has access to network resources by default. Instead, access must be explicitly granted through carefully designed policies. This guide will help you understand how NetBird's policy system works, clarify the important distinction between user groups and peer groups, and provide step-by-step instructions for implementing secure access control in your network.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/update-policy.png" alt="NetBird Policy Update" />
|
||||
</p>
|
||||
|
||||
<Note>
|
||||
**NEW:** For a visual overview of your access policies and how peers, groups, and their relationships connect, check out the [**Control Center**](https://docs.netbird.io/how-to/control-center) feature in NetBird. The Control Center provides an interactive graph view that makes it easy to understand your network's access structure at a glance.
|
||||
</Note>
|
||||
|
||||
## Zero-Trust Principles and NetBird
|
||||
|
||||
Zero-trust networking operates on the principle of "never trust, always verify." Unlike traditional perimeter-based security models, zero-trust assumes that threats can exist both inside and outside the network. NetBird implements this through:
|
||||
|
||||
- **Deny-by-default behavior:** Without policies, no peer can communicate with another peer
|
||||
- **Explicit access grants:** Every connection must be explicitly allowed through a policy
|
||||
- **Identity-based access:** Access can be tied to authenticated identities, not just resources.
|
||||
- **Least privilege access:** Users and devices should only have access to resources they specifically need
|
||||
- **Dynamic posture checks:** Access can be conditional based on device security posture
|
||||
|
||||
## Default ALL to ALL Policy (Not Recommended)
|
||||
|
||||
<Note>
|
||||
**TLDR:** NetBird automatically creates a Default policy that allows all devices to communicate with each other. While this helps with onboarding, the Default policy completely undermines zero-trust principles and should be removed once you create proper access control policies. Make sure to have replacement policies ready before deleting it, or all peer communication will stop.
|
||||
</Note>
|
||||
|
||||
When you first create a NetBird account, a **Default policy** is automatically created that allows all peers to communicate with each other using any protocol. This policy exists because early NetBird users were confused and frustrated when their devices couldn't communicate—NetBird's deny-by-default security model meant nothing worked without policies defined, and users thought the platform was broken.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/all-all-policy.png" alt="NetBird ALL to ALL" />
|
||||
</p>
|
||||
|
||||
The Default policy, which uses the special `All` group as both source and destination, solves this onboarding friction by letting new users immediately see NetBird working while they learn the platform.
|
||||
|
||||
However, **the Default policy completely undermines zero-trust security principles** and should be removed as soon as you're ready to implement proper access control. It violates the principle of least privilege, provides no network segmentation (a compromised device has direct access to everything), and allows all-to-all communication even after you create restrictive policies. Think of it as training wheels: helpful for getting started, but you should remove it when moving to production.
|
||||
|
||||
## Understanding Groups
|
||||
|
||||
### What Are Groups in NetBird?
|
||||
|
||||
Groups in NetBird function similarly to tags or labels in other platforms. They're collections of peers (devices running the NetBird client) and resources (internal network resources that don’t run the NetBird client) that can be used in policies to control network traffic. Every peer in your network can belong to one or more groups, and these group memberships determine what resources that peer can access.
|
||||
|
||||
### User Groups vs. Peer Groups: A Critical Distinction
|
||||
|
||||
This is one of the most important concepts to understand when configuring NetBird access control. **It's important to note that NetBird doesn't technically differentiate between "user groups" and "peer groups" in the interface—all groups appear together in the Groups page.** However, understanding this conceptual distinction is crucial for implementing secure, well-organized access control.
|
||||
|
||||
The distinction is based on **how groups are used and assigned**, not on any technical difference in NetBird:
|
||||
|
||||
### User Groups
|
||||
|
||||
**User groups** are groups that are assigned to user accounts and automatically inherited by any device that user logs into. These are designed for client-side devices used by human users—laptops, workstations, mobile devices, and tablets.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/user-groups.png" alt="NetBird User Groups" />
|
||||
</p>
|
||||
|
||||
**How user groups work:**
|
||||
|
||||
When a user signs into NetBird on a device (such as a Windows computer using the desktop client or a smartphone using the mobile app), that device automatically receives all group memberships assigned to that user account. This typically happens manually on invite or through your Identity Provider (IdP) integration.
|
||||
|
||||
1. **IdP Integration:** User groups are defined in your identity provider (such as Okta, Azure AD, Google Workspace, etc.)
|
||||
2. **Automatic Assignment:** When a user signs into NetBird with SSO on their device, that device (peer) automatically inherits the user's group memberships
|
||||
3. **Dynamic Updates:** If a user's group membership changes in the IdP, their device's access permissions update accordingly
|
||||
|
||||
**Methods for assigning user groups to peers:**
|
||||
|
||||
- **Automatic via SSO:** The recommended method. When users authenticate through your IdP, their device automatically receives the appropriate group assignments
|
||||
- **Manual assignment to users:** Add groups to a user's account in NetBird, then any device that user signs into will inherit those groups
|
||||
- **Direct peer assignment:** You can manually assign user groups directly to specific peers in the Peers section
|
||||
|
||||
**Examples of user groups:**
|
||||
|
||||
- `engineering-team`
|
||||
- `sales-department`
|
||||
- `contractors`
|
||||
- `executives`
|
||||
- `remote-workers`
|
||||
|
||||
### Peer Groups
|
||||
|
||||
**Peer groups** are groups that are assigned directly to infrastructure resources—servers, databases, network appliances, backup systems, and other non-user devices. These resources don't have users logging into them, so groups are assigned either through setup keys or manual assignment.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/peer-groups.png" alt="NetBird Peer Groups" />
|
||||
</p>
|
||||
|
||||
**How peer groups work:**
|
||||
|
||||
1. **Manual Creation:** Groups are created explicitly in the NetBird interface
|
||||
2. **Setup Key Assignment:** The most common method - when creating a setup key, you specify which groups should be [auto-assigned](https://docs.netbird.io/how-to/register-machines-using-setup-keys#peer-auto-grouping) to any peer that registers with that key
|
||||
3. **Manual Assignment:** Administrators can also manually assign groups to specific infrastructure peers after they're connected
|
||||
|
||||
**What are Setup Keys?**
|
||||
|
||||
Setup keys are pre-authentication keys that allow servers and headless devices to register with your NetBird network automatically, without requiring interactive SSO login. When you create a setup key, you can specify which groups should be automatically assigned to any peer that connects using that key.
|
||||
|
||||
**Examples of peer groups:**
|
||||
|
||||
- `production-databases`
|
||||
- `web-servers`
|
||||
- `backup-servers`
|
||||
- `development-environments`
|
||||
- `proxy-hosts`
|
||||
- `network-routers`
|
||||
|
||||
### Why Think of User Groups and Peer Groups Separately?
|
||||
|
||||
Even though NetBird treats all groups the same way technically, maintaining this conceptual separation in your mind and in your naming conventions is crucial for several reasons:
|
||||
|
||||
1. **Security clarity:** Clearly distinguishes between "who" (users) and "what" (resources)
|
||||
2. **Principle of least privilege:** Makes it easier to grant users access only to the specific resources they need
|
||||
3. **Audit and compliance:** Simplified tracking of which users can access which resources
|
||||
4. **Operational clarity:** Prevents confusion about whether a group represents users or infrastructure
|
||||
5. **Policy clarity:** Keeps your access policies clean and easy to understand
|
||||
|
||||
**Anti-pattern to avoid:**
|
||||
❌ Creating a group called `engineering` and adding both engineering team members' laptops AND engineering servers to the same group. While this doesn't automatically grant access between devices (you still need a policy), it creates several problems:
|
||||
|
||||
- If you create an `engineering` → `engineering` policy to allow access, you've now granted all devices in that group access to each other, creating an unclear mesh where laptops can access servers AND servers can access laptops
|
||||
- It makes your access control messy and difficult to audit
|
||||
- You lose clarity about which devices are users vs. infrastructure
|
||||
- It violates zero-trust principles by not maintaining clear source and destination boundaries
|
||||
|
||||
**Correct approach:**
|
||||
✅ Add engineering team users into a `engineering-users` group and set machines or resources to a `engineering-servers` group. Create a setup key with `engineering-servers` as an auto-assigned group, then use that key when deploying servers. Finally, create a policy allowing `engineering-users` (source) to access `engineering-servers` (destination). This keeps your access control clear: users access servers, not the other way around.
|
||||
|
||||
## Policy Direction: Source and Destination
|
||||
|
||||
### The Source-Destination Model
|
||||
|
||||
NetBird policies control network traffic by defining:
|
||||
|
||||
- **Source:** The group of peers that initiate connections
|
||||
- **Destination:** The group of peers that receive connections
|
||||
|
||||
**Important:** Simply being in a group doesn't grant any access. You must create a policy that includes those groups. However, how you organize your groups significantly impacts how clear and secure your policies become.
|
||||
|
||||
### Best Practice: Users as Source, Infrastructure as Destination
|
||||
|
||||
Following zero-trust principles, your policies should generally follow this pattern:
|
||||
|
||||
**✅ Recommended Pattern:**
|
||||
|
||||
- **Source:** User groups (client devices)
|
||||
- **Destination:** Peer groups (servers/infrastructure)
|
||||
|
||||
This ensures that:
|
||||
|
||||
- Users can reach the resources they need
|
||||
- Your policies clearly show the direction of access
|
||||
- Resources cannot initiate connections back to user devices (when using specific ports)
|
||||
- It's easy to audit who has access to what
|
||||
|
||||
**Example:**
|
||||
|
||||
```
|
||||
Policy: Engineering Database Access
|
||||
Source: engineering-users
|
||||
Destination: production-databases
|
||||
Protocol: TCP
|
||||
Ports: 5432 (PostgreSQL)
|
||||
Direction: One-way
|
||||
|
||||
```
|
||||
|
||||
This policy clearly states: engineering users can access production databases. If you had mixed both users and databases into a single `engineering` group and created an `engineering` → `engineering` policy, it would be unclear what's accessing what, and you'd be granting unnecessary bidirectional access.
|
||||
|
||||
### Peer-to-Peer Policies
|
||||
|
||||
There are legitimate cases where infrastructure resources need to communicate with each other:
|
||||
|
||||
**✅ Valid Infrastructure-to-Infrastructure:**
|
||||
|
||||
```
|
||||
Policy: Backup Server Access
|
||||
Source: proxmox-ve
|
||||
Destination: proxmox-backup-server
|
||||
Protocol: TCP
|
||||
Ports: 8007
|
||||
Direction: One-way
|
||||
|
||||
```
|
||||
|
||||
This allows proxy hosts to initiate connections to backup servers for data replication or backup operations.
|
||||
|
||||
### Anti-Pattern: Infrastructure to Users
|
||||
|
||||
**❌ Generally Avoid:**
|
||||
|
||||
```
|
||||
Policy: Server to User Access (NOT RECOMMENDED)
|
||||
Source: web-servers
|
||||
Destination: engineering-users
|
||||
|
||||
```
|
||||
|
||||
While NetBird’s peer-to-peer technology allows servers to connect to laptops and even mobile phones, this is not recommended.
|
||||
|
||||
**Why avoid this?**
|
||||
|
||||
- Violates zero-trust principles
|
||||
- Increases attack surface
|
||||
- If a server is compromised, it could initiate connections to user devices
|
||||
- Doesn't align with typical network communication patterns
|
||||
|
||||
**When might this be acceptable?**
|
||||
In rare cases, such as callback mechanisms or notification systems, you might need servers to reach client devices. In these cases:
|
||||
|
||||
- Document the business justification clearly
|
||||
- Use specific ports and protocols (not "ALL")
|
||||
- Consider alternative architectures (like webhooks or polling)
|
||||
- Implement additional posture checks
|
||||
|
||||
## Policy Directionality
|
||||
|
||||
Understanding policy directionality is essential for implementing Zero Trust access control. How policies behave depends on whether you're connecting to **peers** (devices running NetBird) or **network resources** (internal systems accessed through routing peers).
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/policy-direction.gif" alt="NetBird Policy Direction" className="imagewrapper" />
|
||||
</p>
|
||||
|
||||
### Policies Between Peers
|
||||
|
||||
When both source and destination are peers running the NetBird agent, you have full control over directionality:
|
||||
|
||||
**Unidirectional:** Traffic flows only from source to destination. In the NetBird UI, this appears as a single arrow (→).
|
||||
|
||||
Example:
|
||||
|
||||
```
|
||||
Policy: Database Access
|
||||
Source: app-servers (NetBird peers)
|
||||
Destination: database-servers (NetBird peers)
|
||||
Protocol: TCP
|
||||
Ports: 5432
|
||||
Direction: Source → Destination (unidirectional)
|
||||
```
|
||||
|
||||
App servers can initiate connections to database servers on port 5432, but database servers cannot initiate NEW connections back to app servers on that port. Return traffic for established connections is handled automatically by NetBird's stateful firewall.
|
||||
|
||||
**Bidirectional:** Both groups can initiate connections to each other. In the NetBird UI, you can enable this by clicking the bidirectional arrows (⟷).
|
||||
|
||||
Example:
|
||||
|
||||
```
|
||||
Policy: Dev Cluster Communication
|
||||
Source: kubernetes-nodes (NetBird peers)
|
||||
Destination: kubernetes-nodes (NetBird peers)
|
||||
Protocol: ALL
|
||||
Direction: Bidirectional (both can initiate)
|
||||
```
|
||||
|
||||
All Kubernetes nodes can initiate connections to each other. This is useful for infrastructure components that need to coordinate.
|
||||
|
||||
**Alternative approach for bidirectional (less common):** Instead of using the bidirectional toggle, you could create two separate policies with reversed source and destination. However, using the bidirectional toggle in a single policy is the recommended approach.
|
||||
|
||||
### Policies to Network Resources
|
||||
|
||||
**IMPORTANT:** When the destination is a **network resource** accessed through a routing peer (not a peer running NetBird directly), policies are **ALWAYS unidirectional** and can ONLY flow from source to destination.
|
||||
|
||||
Example:
|
||||
|
||||
```
|
||||
Policy: Access to Private Network
|
||||
Source: engineering-users (NetBird peers)
|
||||
Destination: office-lan (Network resource: 10.0.1.0/24)
|
||||
Protocol: TCP
|
||||
Ports: 22, 443
|
||||
Direction: ALWAYS Source → Destination (cannot be bidirectional)
|
||||
|
||||
```
|
||||
|
||||
**Why is this always unidirectional?**
|
||||
|
||||
Network resources don't have the NetBird agent installed. They don't know the NetBird network exists. The routing peer acts as a gateway, forwarding traffic from NetBird peers to these resources, but the resources themselves cannot initiate connections back through the NetBird network.
|
||||
|
||||
Think of it this way:
|
||||
|
||||
- ✅ Your laptop (NetBird peer) → Routing peer → Office printer (network resource) = **Works**
|
||||
- ❌ Office printer (network resource) → Routing peer → Your laptop (NetBird peer) = **Impossible** (printer doesn't know about NetBird)
|
||||
|
||||
**UI Behavior:** When creating a policy where the destination is a network resource, the bidirectional toggle will either be disabled or attempting to enable it will have no effect, because bidirectional communication is not possible in this scenario.
|
||||
|
||||
### Protocol-Specific Behavior
|
||||
|
||||
Policy directionality also depends on the protocol selected:
|
||||
|
||||
**Always Bidirectional (regardless of UI setting):**
|
||||
|
||||
- **ALL protocol**: Both directions can always initiate connections
|
||||
- **ICMP**: Both directions can always initiate (for ping, etc.)
|
||||
- **TCP/UDP without specific ports**: Both directions can initiate connections
|
||||
|
||||
**Can Be Unidirectional (when ports are specified):**
|
||||
|
||||
- **TCP with specific ports**: Can be unidirectional (only source initiates on those ports)
|
||||
- **UDP with specific ports**: Can be unidirectional (only source initiates on those ports)
|
||||
|
||||
Example:
|
||||
|
||||
```
|
||||
Policy: Web Application Access
|
||||
Source: users
|
||||
Destination: web-servers
|
||||
Protocol: TCP
|
||||
Ports: 443
|
||||
Direction: Unidirectional (users → web-servers on port 443)
|
||||
```
|
||||
|
||||
Even though this is unidirectional, return traffic (HTTPS responses) is automatically allowed because NetBird implements a stateful firewall that tracks established connections.
|
||||
|
||||
### Platform-Specific Implementation
|
||||
|
||||
**Linux Platforms:** NetBird integrates with native Linux firewall capabilities using connection tracking rules (`ct state established,related accept`). The kernel's connection tracking handles reply traffic automatically.
|
||||
|
||||
**Non-Linux Platforms:** NetBird implements a stateful firewall in userspace with a connection tracker that dynamically creates temporary rules for reply traffic:
|
||||
|
||||
- **TCP**: Full state machine tracking
|
||||
- **UDP/ICMP**: Session tracking using timeouts
|
||||
|
||||
This replicates Linux firewall connection state handling in userspace.
|
||||
|
||||
## Multiple Mesh Networks
|
||||
|
||||
As mentioned above, policies define how your network behaves as a mesh network, but **only when you create the policies**. Without policies, peers cannot communicate even if they're in the same group.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/mesh-policy.png" alt="NetBird Mesh Policy" />
|
||||
</p>
|
||||
|
||||
There is a Default policy, which configures a default mesh connection between all peers of your network using the `All` group. With custom policies, you can define smaller, more controlled mesh networks by grouping peers and adding these groups to Source and Destination lists.
|
||||
|
||||
**Example of an intentional mesh:**
|
||||
|
||||
```
|
||||
Policy: Dev Cluster Communication
|
||||
Source: kubernetes-nodes
|
||||
Destination: kubernetes-nodes
|
||||
Protocol: ALL
|
||||
Direction: Bi-directional
|
||||
|
||||
```
|
||||
|
||||
This creates a mesh where all Kubernetes nodes can communicate freely with each other. This makes sense because these are all infrastructure components that need to coordinate.
|
||||
|
||||
**Why you wouldn't want a user-infrastructure mesh:**
|
||||
|
||||
```
|
||||
Policy: Engineering Mesh (NOT RECOMMENDED)
|
||||
Source: engineering-mixed (contains both user laptops and servers)
|
||||
Destination: engineering-mixed
|
||||
Protocol: ALL
|
||||
|
||||
```
|
||||
|
||||
This creates an unclear mesh where laptops, servers, and everything else can all access each other bidirectionally. It's impossible to tell from this policy what's actually happening, and you've likely granted more access than needed.
|
||||
|
||||
## Advanced Patterns and Use Cases
|
||||
|
||||
### Pattern 1: Port Ranges for Application Suites
|
||||
|
||||
When dealing with applications that use multiple ports:
|
||||
|
||||
```
|
||||
Policy: Engineering Kubernetes Access
|
||||
Source: engineering-team
|
||||
Destination: kubernetes-clusters
|
||||
Protocol: TCP
|
||||
Ports: 6443, 8080-8090, 10250-10255
|
||||
Direction: One-way
|
||||
|
||||
```
|
||||
|
||||
### Pattern 2: Contractor Limited Access
|
||||
|
||||
For temporary or limited-access users:
|
||||
|
||||
```
|
||||
Policy: Contractor Limited Access
|
||||
Source: contractors
|
||||
Destination: contractor-resources
|
||||
Protocol: TCP
|
||||
Ports: 443, 22
|
||||
Direction: One-way
|
||||
Posture Checks: [NetBird Latest Version]
|
||||
|
||||
```
|
||||
|
||||
### Pattern 3: Management Network Separation
|
||||
|
||||
Create a separate management network for administrative access:
|
||||
|
||||
```
|
||||
Policy: Admin Management Access
|
||||
Source: admin-team
|
||||
Destination: management-interfaces
|
||||
Protocol: TCP
|
||||
Ports: 22, 443, 3389
|
||||
Direction: One-way
|
||||
|
||||
```
|
||||
|
||||
### Pattern 4: Service-to-Service Communication
|
||||
|
||||
For microservices or distributed applications:
|
||||
|
||||
```
|
||||
Policy: API Gateway to Backend Services
|
||||
Source: api-gateways
|
||||
Destination: backend-services
|
||||
Protocol: TCP
|
||||
Ports: 8080, 8443, 9090
|
||||
Direction: One-way
|
||||
|
||||
```
|
||||
|
||||
## Conclusion
|
||||
|
||||
NetBird's access control system provides powerful, flexible tools for implementing zero-trust networking. By understanding the distinction between user groups and peer groups, following the principle of users-as-source and infrastructure-as-destination, and creating specific policies for each access requirement, you can build a secure, manageable network that follows security best practices.
|
||||
|
||||
**Key takeaways:**
|
||||
|
||||
1. **Remove the Default policy** and create specific policies aligned with your access requirements
|
||||
2. **Keep user groups conceptually separate from peer groups** for clarity and security, even though NetBird treats them the same way
|
||||
3. **Generally use user groups as Source** and infrastructure peer groups as Destination
|
||||
4. **Use setup keys with auto-assigned groups** to automate infrastructure deployment
|
||||
5. **Use specific protocols and ports** rather than ALL when possible
|
||||
6. **Implement posture checks** for sensitive resources
|
||||
7. **Document your policies** and review them regularly
|
||||
|
||||
By following these principles, you'll create a network that embodies zero-trust security while remaining manageable and understandable for your team.
|
||||
215
src/pages/manage/access-control/manage-network-access.mdx
Normal file
215
src/pages/manage/access-control/manage-network-access.mdx
Normal file
@@ -0,0 +1,215 @@
|
||||
# Managing Access with NetBird: Groups and Access Policies
|
||||
|
||||
NetBird empowers administrators to effectively manage and control access between resources (referred to as peers) using groups and access policies.
|
||||
These access policies define which peers or peer groups are allowed to connect, specify the protocols and ports available
|
||||
for these connections, and optionally incorporate posture checks. By integrating posture checks, NetBird enforces
|
||||
zero-trust principles, enabling dynamic and context-aware access control that adapts to the specific security needs of
|
||||
your environment.
|
||||
|
||||
Watch our Access Control video on YouTube:
|
||||
|
||||
<div className="videowrapper">
|
||||
<iframe src="https://www.youtube.com/embed/WtZD_q-g_Jc" allow="fullscreen;"></iframe>
|
||||
</div>
|
||||
|
||||
<Note>
|
||||
For a visual overview of your access policies and network topology, check out the [Control Center](/how-to/control-center), which provides an interactive graph view of peers, groups, and their access relationships.
|
||||
</Note>
|
||||
|
||||
## Introduction
|
||||
Initially, a NetBird account is configured with a `Default` policy which allows peers to connect via any protocol, resulting in the formation of a full mesh network. This setup often suits small networks or those requiring minimal security. In scenarios where higher security is needed or access to specific resources must be restricted for certain users or services, policies can be set up to determine access permissions.
|
||||
|
||||
|
||||
Access control policies make use of groups to control connections between peers. These groups, which are sets of peers (meaning different machines with the NetBird client installed), can be added as Source or Destination of a policy. They are evaluated when the Management service distributes the list of peers across your network.
|
||||
|
||||
## Concepts
|
||||
### Groups
|
||||
A NetBird group works and follows a similar concept to tags in other platforms; they are easily created and can be associated with peers and used in policies to control traffic within your network.
|
||||
|
||||
Here are some key attributes of groups:
|
||||
- Each group is unique.
|
||||
- A single group can have multiple peers.
|
||||
- Peers can be part of multiple groups simultaneously.
|
||||
- Groups can be included in the 'Source' and 'Destination' lists of policies.
|
||||
- Groups can be created either in `Access Control > Groups` or in places where a group input field is provided. Type the preferred group name into the input and press 'Enter' to create the new group. [Learn more](#creating-groups)
|
||||
- Groups can be deleted in `Access Control > Groups` [Learn more](#deleting-groups)
|
||||
- There exists a default group called `All` which cannot be deleted or renamed.
|
||||
|
||||
<Note>
|
||||
You can assign groups automatically with the [peer auto-grouping feature](/how-to/register-machines-using-setup-keys#peer-auto-grouping).
|
||||
</Note>
|
||||
|
||||
### The All Group
|
||||
The 'All' group serves as a default group that automatically includes every peer in your network. This group cannot be modified or removed.
|
||||
|
||||
### Policies
|
||||
Policies act as rules governing how different resources (peers) can communicate and connect. They specify the source and destination of communication and can allow bidirectional or unidirectional connections.
|
||||
|
||||
Policies are processed when the Management service shares a network map with all peers of your account. Because you can only create ALLOW policies, there is no processing order or priority. So, the decision to distribute peer information is based on its association with a group belonging to an existing policy.
|
||||
|
||||
For ICMP and ALL protocols, as well as for TCP and UDP protocols **without** specific port restrictions, communication between groups listed in the source and destination fields is bidirectional. This means that both source and destination groups can initiate connections with each other. To establish one-way connections, you must specify a protocol (UDP or TCP), along with a port.
|
||||
|
||||
<Note>
|
||||
If you need to allow peers from the same group to communicate with each other, you can do so by adding the same group to the `Source` and `Destination` lists.
|
||||
</Note>
|
||||
|
||||
Without policies, a network operates by denying traffic, meaning peers cannot communicate with each other. That's why the default policy is automatically created upon account creation.
|
||||
|
||||
|
||||
### The Default policy
|
||||
The `Default` policy is created when you first create your account. This policy is very permissive because it allows communication between all peers in your network, utilizing the [`All`](#the-all-group) group as both the source and destination. It's worth noting that the [`All`](#the-all-group) group is also automatically present when the account is being created. If you want to have better control over your network, it is recommended that you delete this policy and create more restricted policies with custom groups.
|
||||
|
||||
<Note>
|
||||
If you need to restrict communication within your network, you can create new policies and use different groups. Then, you can remove the default policy to achieve the desired behavior.
|
||||
</Note>
|
||||
|
||||
### Multiple Mesh Networks
|
||||
As mentioned above, policies are bidirectional by default, essentially controlling how your network behaves as a mesh network. However, for TCP and UDP protocols, if you specify ports in the policy, it can become unidirectional.
|
||||
|
||||
There is a `Default` policy, which configures a default mesh connection between all peers of your network. With policies, you can define smaller mesh networks by grouping peers and adding these groups to `Source` and `Destination` lists. Additionally, you can create unidirectional policies to restrict traffic between groups for TCP and UDP protocols if you define ports.
|
||||
|
||||
## Managing Policies
|
||||
|
||||
### Creating Policies
|
||||
After accessing the `Access Control` > `Policies` tab, click on the `Add policy` button to create a new policy.
|
||||
In the popup, specify connection `Source` and `Destination` groups. You can select existing groups or create new ones by entering a name in the input box.
|
||||
|
||||
<Note>
|
||||
We recommend using [identity provider (IdP) integrations](/how-to/idp-sync) to provision your user groups from the IdP.
|
||||
</Note>
|
||||
|
||||
You can limit access to specific protocol and ports by selecting the `Protocol` and providing the port numbers in the `Ports` field.
|
||||
Starting version `0.48` NetBird supports port ranges in policies, allowing you to specify a range of ports in the format `start-end` (e.g., `8000-9000`).
|
||||
Make sure to set traffic direction only when TCP or UDP protocols are selected. Finally, provide a name and description for your policy.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/overview/create-rule.png" alt="high-level-dia" className="imagewrapper"/>
|
||||
</p>
|
||||
If necessary, you can also add a [posture checks](/manage/access-control/posture-checks) to the policy. Posture checks are used to ensure that the peer meets certain security requirements before allowing it to connect. You can select from predefined posture checks or create custom ones.
|
||||
|
||||
Once you have finished configuring the policy, click `Add Policy` to save it. You will then see your new policy in the table.
|
||||
<p>
|
||||
<img src="/docs-static/img/overview/new-rule-list.png" alt="high-level-dia" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
<Note>
|
||||
Because of its permissiveness, new policies will take effect once you remove the `Default` policy.
|
||||
</Note>
|
||||
|
||||
<Note>
|
||||
Protocol type All or ICMP must be bi-directional. Also unidirectional traffic for TCP and UDP protocol requires at least one port to be defined.
|
||||
</Note>
|
||||
|
||||
### Adding peers to groups
|
||||
If you create a new group when defining a policy, you will need to add a peer to the group for the policy to take effect.
|
||||
You can assign a peer to a group by accessing the `Peers` section. Then, choose the specific peer you want to assign to a group. Click on the `Assigned Groups` select box and select the group(s) you wish to assign to this peer.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/overview/associate-peer-groups.png" alt="high-level-dia" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
<Note>
|
||||
You can assign groups automatically with the [peer auto-grouping feature](/how-to/register-machines-using-setup-keys#peer-auto-grouping).
|
||||
</Note>
|
||||
|
||||
### Updating Policies
|
||||
|
||||
To update a policy, just click on its name and customize it according to your requirements. This action will open the same screen where you can update policy groups, descriptions, and status, or modify allowed traffic direction, protocols with ports, and posture checks, similar to the information described in the "Creating Policies" section above.
|
||||
|
||||
### Disabling Policies
|
||||
To disable a policy, use the switch in the `Active` column of the table.
|
||||
<p>
|
||||
<img src="/docs-static/img/overview/disable-rule.png" alt="high-level-dia" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
### Deleting Policies
|
||||
To delete a policy, click on `Delete` in the table, and confirm the message that appears.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/overview/delete-rule-menu.png" alt="high-level-dia" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
## Managing Groups
|
||||
|
||||
### Creating Groups
|
||||
|
||||
You can create groups in two ways:
|
||||
|
||||
**Quick Creation (Inline)**<br/>
|
||||
When you see a group input field anywhere in the dashboard (e.g. such as when creating policies), you can create groups directly from the input field.
|
||||
1. Type your preferred group name into the input field
|
||||
2. Press 'Enter' to create the new group
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/groups/create-group-input.png" alt="Create group inline" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
**From Groups Page**<br/>
|
||||
1. Navigate to `Access Control` > `Groups`
|
||||
2. Click the `Create Group` button
|
||||
3. Provide a name for your new group
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/groups/create-group.png" alt="Create group from groups page" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
### Viewing Groups
|
||||
|
||||
**Groups Overview**<br/>
|
||||
Navigate to `Access Control` > `Groups` to view all groups in your organization. This page shows:
|
||||
- All existing groups
|
||||
- Associated objects (peers, users, policies, etc.)
|
||||
- Usage status (used/unused groups)
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/groups/view-groups.png" alt="Groups overview page" className=""/>
|
||||
</p>
|
||||
|
||||
**Group Details**<br/>
|
||||
Navigate to `Access Control` > `Groups` and then click on any group name to view detailed information and manage associated objects:
|
||||
|
||||
- **Users**: View, assign, or invite users to this group
|
||||
- **Peers**: Manage which peers are assigned to this group
|
||||
- **Policies**: See policies where this group is used as a source or destination
|
||||
- **Network Resources**: View associated resources from networks
|
||||
- **Network Routes**: See network routes using this group (either part of the distribution, access control, or routing peer group)
|
||||
- **Nameservers**: View nameservers using this group as a distribution group
|
||||
- **Setup Keys**: See setup keys with this group as an auto-assigned group
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/groups/view-group-detail.png" alt="Group details page" className=""/>
|
||||
</p>
|
||||
|
||||
### Renaming Groups
|
||||
|
||||
1. Navigate to `Access Control` > `Groups`
|
||||
2. Click the dropdown button (⋮) next to the group you want to rename
|
||||
3. Select `Rename`
|
||||
4. Enter the new name and click `Save`
|
||||
|
||||
<Note>
|
||||
Groups synchronized from Identity Providers (Google Workspace, Entra ID, etc.) cannot be renamed.
|
||||
</Note>
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/groups/rename-group.png" alt="Rename group" className=""/>
|
||||
</p>
|
||||
|
||||
### Deleting Groups
|
||||
|
||||
1. Navigate to `Access Control` > `Groups`
|
||||
2. Click the dropdown button (⋮) next to the group you want to delete
|
||||
3. Select `Delete`
|
||||
4. Confirm the action by clicking `Delete` in the confirmation dialog
|
||||
|
||||
<Note>
|
||||
Groups synchronized from Identity Providers (Google Workspace, Entra ID, etc.) cannot be deleted.
|
||||
</Note>
|
||||
|
||||
<Note>
|
||||
Groups with active dependencies cannot be deleted. First remove all dependencies in order to delete the group.
|
||||
</Note>
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/groups/delete-group.png" alt="Delete group" className=""/>
|
||||
</p>
|
||||
@@ -0,0 +1,102 @@
|
||||
# Connecting from the office
|
||||
A typical scenario administrators have is accessing their office networks remotely. With [Network routes](https://docs.netbird.io/how-to/routing-traffic-to-private-networks), NetBird makes this easy. Still, administrators often want to avoid routing their users’ traffic via NetBird when they are in the office.
|
||||
To solve this, administrators can leverage the power of [Posture Checks](https://docs.netbird.io/manage/access-control/posture-checks) and create policies that allow connection to the routing peers only if they are outside the office by using
|
||||
a [Peer Network Range](/manage/access-control/posture-checks#peer-network-range) posture check with a block action.
|
||||
|
||||
## Example
|
||||
In the following scenario, our office network is on the subnet `192.168.1.0/24`. Let's assume all users will be part of the group `route-users`, and the routing peer for our office will be inside the group `route-nodes`.
|
||||
With this in mind, the goal is to create a Posture Check, create a Policy and assign a Posture Check to it, and finally create a Network Route that will expose the office subnet.
|
||||
|
||||
### Create a Posture Check
|
||||
To create a Posture Check, navigate to the `Access Control -> Posture Checks` section in the NetBird dashboard and click on **Add Posture Check**.
|
||||
|
||||
Select `Peer Network Range`.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/posture-checks/connecting-from-the-office/posture-check-new-block-network-range.png" alt="high-level-dia" className="imagewrapper"/>
|
||||
</p>
|
||||
Select the `Block` action and click on `Add Network Range` to input your office subbnet `192.168.1.0/24`.
|
||||
<Note>
|
||||
Note that if you have multiple locations that you want to see excluded, you can add multiple network ranges.
|
||||
</Note>
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/posture-checks/connecting-from-the-office/posture-check-block-network-range.png" alt="high-level-dia" className="imagewrapper"/>
|
||||
</p>
|
||||
Click `Save`, then click `Continue` and fill out `Name of the Posture Check` with "Exclude Office subnet”.
|
||||
|
||||
After we conclude this step, we are ready to create a policy and assign this posture check.
|
||||
### Create a Policy
|
||||
We start by creating a simple policy that will allow access from group `route-users` to group `route-nodes`.
|
||||
This is needed to establish the connection between the users and the routing peer.
|
||||
|
||||
Navigate to the `Access Control -> Policies` section in the NetBird dashboard and click on `Add Policy`.
|
||||
|
||||
On the `Source` field, select the group `route-user`, and on the `Destination` field, select the group `route-nodes`.
|
||||
Choose `UDP` for the protocol and type `1`on Ports. Click `Continue`.
|
||||
<Note>
|
||||
Note that the protocol and port are arbitrary and can be changed according to your needs. An usual choice is to allow ICMP traffic for troubleshooting purposes.
|
||||
</Note>
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/posture-checks/connecting-from-the-office/policy-office-subnet-with-posturecheck.png" alt="high-level-dia" className="imagewrapper"/>
|
||||
</p>
|
||||
In this step, we'll click `Browse Checks` and select the posture check we created earlier, `Exclude Office subnet`.
|
||||
|
||||
Click `Add Posture Checks` and then click `Continue`.
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/posture-checks/connecting-from-the-office/policy-with-network-posturecheck-added.png" alt="high-level-dia" className="imagewrapper"/>
|
||||
</p>
|
||||
Give your policy the name "Allow users to route-nodes" and click on `Add Policy`.
|
||||
|
||||
We are now ready for the final step of creating the office route.
|
||||
|
||||
### Create a Network Route
|
||||
|
||||
Now, let's create a [Network Route](https://docs.netbird.io/how-to/routing-traffic-to-private-networks) that will expose the local office subnet `192.168.1.0/24`,
|
||||
which will be distributed to all peers members of the group `route-users`. In this example, we will be using a routing peer named `router-01`,
|
||||
which is a member of the group `route-nodes`, this way, the policy we just created goes into effect, and all peers from the group `route-users` will be able to reach
|
||||
`router-01` only if they are not in the office network, due to our posture check.
|
||||
|
||||
To get started navigate to `Network Routes` menu on the NetBird dashboard and click on **Add Route**. Fill out the fields as shown in the image below, and click `Continue`:
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/posture-checks/connecting-from-the-office/create-route-with-posturecheck.png" alt="high-level-dia" className="imagewrapper"/>
|
||||
</p>
|
||||
Next assign `route-users` do `Distribution Groups`.
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/posture-checks/connecting-from-the-office/distribute-to-groups-posturechecks.png" alt="high-level-dia" className="imagewrapper"/>
|
||||
</p>
|
||||
Click `Continue` and assign the name "Office network access" to `Network Identifier`, click `Continue` agaom and in the final step, finish this process by clicking `Add Route`.
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/posture-checks/connecting-from-the-office/route-office-subnet-posturecheck.png" alt="high-level-dia" className="imagewrapper"/>
|
||||
</p>
|
||||
### Testing Posture Check
|
||||
Now that we have created the Posture Check, the Policy, and the Network Route, we can test this configuration. In the following example, we will be testing this Posture Check from a macOS client named `client-01`, and as stated earlier, it belongs to the group `route-users`.
|
||||
|
||||
#### While connect from inside our office:
|
||||
Our local connection shows that we are connected to local office WiFi and and we are part of that subnet.
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/posture-checks/connecting-from-the-office/wifi-inside-office-subnet.png" alt="high-level-dia" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
When we are connected from inside the office, we can observe that the NetBird route is not available and that the subnet `192.168.1` is using local network interface `en0` to route traffic.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/posture-checks/connecting-from-the-office/netbird-routes-list-local.png" alt="high-level-dia" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/posture-checks/connecting-from-the-office/netstat-routes-grep-local.png" alt="high-level-dia" className="imagewrapper"/>
|
||||
</p>
|
||||
#### When connected outside the office, we can observe:
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/posture-checks/connecting-from-the-office/netbird-routes-list-external.png" alt="high-level-dia" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/access-control/posture-checks/connecting-from-the-office/netstat-routes-grep-external.png" alt="high-level-dia" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
Notice that subnet `192.168.1.0/24` is routed through our Wireguard interface (`utun100`).
|
||||
|
||||
As you can see, the Posture Check is working as expected, and the traffic is being routed through NetBird only when the client is outside the office network.
|
||||
This concludes this Posture Check example.
|
||||
113
src/pages/manage/access-control/posture-checks/index.mdx
Normal file
113
src/pages/manage/access-control/posture-checks/index.mdx
Normal file
@@ -0,0 +1,113 @@
|
||||
# Understanding NetBird Posture Checks
|
||||
Posture Checks is a security feature that enhances network protection by implementing automated assessments of a device's security status before granting network access, thus ensuring that only compliant devices can access your network resources.
|
||||
|
||||
In this regard, NetBird posture checks verify various aspects of a connecting device, offering granular control over network access. These checks include **verifying the NetBird client version**, allowing you to restrict access to peers with specific versions of the client software. Additionally, you can implement **geographical restrictions** based on country or region, giving you control over where connections can originate from.
|
||||
|
||||
The feature also allows for network-level restrictions by enabling you to **allow or block specific peer network ranges**. Furthermore, you can set constraints based on the operating system of the connecting device, **ensuring that only approved OS versions can gain access**. For an even more detailed level of control, Posture Checks can examine the running processes on a peer device, **allowing or denying access based on the presence of specific applications or services**.
|
||||
|
||||
By using these diverse checking capabilities, NetBird empowers you to create a robust and finely-tuned security posture for your network, significantly reducing the risk of unauthorized access and potential security breaches.
|
||||
|
||||
## Setting Up Posture Checks
|
||||
|
||||
Setting up posture checks in NetBird is straightforward, you can follow the example in the video below:
|
||||
<div className="videowrapperadjusted" >
|
||||
<iframe src="https://www.youtube.com/embed/-KlJUBuZrpo" allow="fullscreen;"></iframe>
|
||||
</div>
|
||||
|
||||
Or follow the guide with other examples below:
|
||||
|
||||
Log in to your NetBird dashboard and navigate to `Access Control` > `Posture Checks` in the left menu. Click `Create Posture Check` or edit an existing one.
|
||||
|
||||
|
||||
|
||||
A pop-up window will open with two tabs: `Checks` and `Name & Description`.
|
||||
|
||||
|
||||
|
||||
From here, you can manage access with posture checks based on several aspects:
|
||||
|
||||
### NetBird Client Version
|
||||
Restrict access to peers with specific NetBird client versions, thus ensuring that all devices connecting to the network use up-to-date, secure client software.
|
||||
|
||||
|
||||
|
||||
### Country and Region
|
||||
Limit network access based on geographical location, helping comply with data regulations or restrict access from high-risk areas. Note that you have two tabs available for this: `Allow` (green) and `Block` (red), making it easy to set up your preferred access rules..
|
||||
|
||||
|
||||
<Note>
|
||||
When allowing access from specific locations in the network settings, all other locations are automatically blocked. Conversely, blocking certain locations means only those are blocked, while access remains open for all other locations.
|
||||
</Note>
|
||||
#### Peer Network Range
|
||||
This posture check lets you precisely control network access by specifying which IP ranges can connect to your network. You can create policies allowing only connections from approved locations, such as office networks or trusted remote work setups. Additionally, you can enhance security by blocking high-risk IP ranges working in tandem with geo-based posture checks. This granular control helps create a more secure network environment by limiting access to known, trusted sources while preventing connections from potentially risky or unauthorized IP addresses.
|
||||
|
||||
|
||||
|
||||
### Operating System
|
||||
Restrict access based on the connecting device's OS, ensuring only approved and potentially more secure operating systems can connect.
|
||||
|
||||
|
||||
<Note>
|
||||
The Operating System Check requires NetBird version [0.26.0](https://github.com/netbirdio/netbird/releases) or newer.
|
||||
</Note>
|
||||
|
||||
The check evaluates the actual `OS version` for Android, macOS, and iOS, while for Linux and Windows, it assesses the `kernel version`.
|
||||
|
||||
Below are some examples of OS versions for each operating system:
|
||||
|
||||
* Android 14 Upside Down Cake: `14`, `14.3`
|
||||
* macOS 13 Ventura: `13`, `13.6.4`
|
||||
* macOS 14 Sonoma: `14`, `14.3.1`
|
||||
* iOS 16 / iPadOS 16: `16`, `16.7.5`
|
||||
* Linux kernel: `6`, `6.7.5`
|
||||
* Windows 10, version 22H2: `10.0.19045`
|
||||
* Windows 11, version 23H2: `10.0.22631`
|
||||
* Windows Server 2022, Version 21H2: `10.0.20348`
|
||||
|
||||
### Process
|
||||
[Limit network access based on specific applications or services running on the connecting device](https://netbird.io/knowledge-hub/limit-network-access-based-on-running-processes). By verifying specific applications or processes, you ensure that only devices running essential security software, such as antivirus, firewalls, or endpoint protection agents, can connect to your network, reducing the risk of malware entering your network through unprotected devices. It also aids in maintaining compliance with regulatory requirements by enforcing consistent security measures across all devices.
|
||||
|
||||
Furthermore, this process-based posture check allows you to create specific policies for different user groups or network segments based on their unique security needs. Working in conjunction with other posture checks in NetBird, this setting offers a comprehensive and user-friendly approach to network security.
|
||||
|
||||
|
||||
|
||||
## Name & Description
|
||||
After enabling the desired posture check, go to the `Name & Description` tab. Here, enter a descriptive name for your newly created posture check and save it.
|
||||
|
||||
|
||||
|
||||
You'll notice a gray dot to the left of the posture check name, indicating it's inactive. To activate the posture check, you need to link it to an access control policy.
|
||||
|
||||
|
||||
|
||||
## Applying Posture Checks to Access Control Policies
|
||||
|
||||
To apply a posture check:
|
||||
|
||||
* [Create or edit an access control policy](https://docs.netbird.io/access-control).
|
||||
* Find the `Posture Checks` tab within the policy settings.
|
||||
* Choose `Browse Checks` to select an existing check or `New Posture Check` to create one.
|
||||
|
||||
Note that you can add multiple posture checks to a single policy as needed for comprehensive security.
|
||||
|
||||
|
||||
|
||||
After adding the posture check, it will appear in the `POSTURE CHECKS` column. For easy management, you can click on it to edit the access control policy, allowing you to add or remove posture checks as needed.
|
||||
|
||||
|
||||
|
||||
If you revisit the `Posture Checks` dashboard, you'll notice a green dot next to your recently configured posture check. This color shift indicates that the posture check is now active and integrated into your network security framework, actively contributing to your system's protection.
|
||||
|
||||
|
||||
|
||||
Following these steps, you can effectively implement and manage NetBird's Posture Checks, significantly enhancing your network's security posture.
|
||||
|
||||
## Get started with NetBird
|
||||
<p float="center" >
|
||||
<Button name="button" className="button-5" onClick={() => window.open("https://netbird.io/pricing")}>Use NetBird</Button>
|
||||
</p>
|
||||
|
||||
- Make sure to [star us on GitHub](https://github.com/netbirdio/netbird)
|
||||
- Follow us [on X](https://x.com/netbird)
|
||||
- Join our [Slack Channel](/slack-url)
|
||||
- NetBird [latest release](https://github.com/netbirdio/netbird/releases) on GitHub
|
||||
Reference in New Issue
Block a user