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
2025-11-18 10:30:45 -08:00
committed by GitHub
parent 5cc53f4ec4
commit a8f91c38b1
99 changed files with 586 additions and 145 deletions

View File

@@ -8,7 +8,7 @@ const howToGuides = [
description: 'Start using NetBird in under 5 minutes.',
},
{
href: '/how-to/manage-network-access',
href: '/manage/access-control/manage-network-access',
name: 'Manage network access',
description:
'Learn how to use access controls to manage access to your machines.',

View File

@@ -99,23 +99,24 @@ export const docsNavigation = [
title: 'Access Control',
isOpen: false,
links: [
{ title: 'Groups & Policies', href: '/how-to/manage-network-access' },
{ title: 'Groups & Policies', href: '/manage/access-control' },
{ title: 'Manage Access', href: '/manage/access-control/manage-network-access' },
{
title: 'Posture Checks',
href: '/how-to/manage-posture-checks',
href: '/manage/access-control/posture-checks',
isOpen: false,
links: [
{ title: 'Disable route when in the office', href: '/how-to/disabling-network-route-when-connecting-from-the-office' },
{ title: 'Disable route when in the office', href: '/manage/access-control/posture-checks/connecting-from-the-office' },
]
},
{
title: 'Integrate MDM & EDR',
href: '/how-to/endpoint-detection-and-response',
href: '/manage/access-control/endpoint-detection-and-response',
isOpen: false,
links: [
{ title: 'CrowdStrike Falcon', href: '/how-to/crowdstrike-edr' },
{ title: 'Microsoft Intune', href: '/how-to/intune-mdm' },
{ title: 'SentinelOne Singularity', href: '/how-to/sentinelone-edr' },
{ title: 'CrowdStrike Falcon', href: '/manage/access-control/endpoint-detection-and-response/crowdstrike-edr' },
{ title: 'Microsoft Intune', href: '/manage/access-control/endpoint-detection-and-response/intune-mdm' },
{ title: 'SentinelOne Singularity', href: '/manage/access-control/endpoint-detection-and-response/sentinelone-edr' },
]
},

View File

@@ -31,7 +31,7 @@ to each other directly via an encrypted point-to-point WireGuard tunnel.
</p>
While it is possible to create a full mesh network, it might be not a desirable outcome.
In this case, [groups and access controls](/how-to/manage-network-access) can be utilized to limit the access to certain machines.
In this case, [groups and access controls](/manage/access-control/manage-network-access) can be utilized to limit the access to certain machines.
Let's now take a closer look at each of NetBird's components.

View File

@@ -113,7 +113,7 @@ Once you save your policy, it is a good practice to disable or modify the defaul
This tailored access policy ensures that only authorized devices (your local machine) can communicate with the Kubernetes cluster, significantly improving your network's security posture. As your environment scales, this policy will automatically apply to new pods, maintaining consistent access control.
For more detailed information on configuring access policies, refer to the [NetBird Access Policies documentation](/how-to/manage-network-access).
For more detailed information on configuring access policies, refer to the [NetBird Access Policies documentation](/manage/access-control/manage-network-access).
## 4. Deploying a Sample Application with NetBird Agent

View File

@@ -21,7 +21,7 @@ In this scenario, an AI software company needs secure access to its internal dom
### Implementation Steps
- **Network Setup**: Using NetBird's Networks you can configure a secure network that connects local and remote users to these internal environments through routing peers. This involves configuring wildcard domains for both environments to enable seamless access while accommodating future growth.
- **Access Control**: NetBird's [Access Policies](https://docs.netbird.io/how-to/manage-network-access) allows you to implement stringent policies that enforce zero trust principles, assigning different access permissions to developers and data scientists. For instance, you can grant developers access to `*.dev.example.com`, while data scientists gain access to `*.ai.example.com`. This clear separation ensures that team members only access the resources essential to their roles, maintaining a robust security posture.
- **Access Control**: NetBird's [Access Policies](https://docs.netbird.io/manage/access-control/manage-network-access) allow you to implement stringent policies that enforce zero trust principles, assigning different access permissions to developers and data scientists. For instance, you can grant developers access to `*.dev.example.com`, while data scientists gain access to `*.ai.example.com`. This clear separation ensures that team members only access the resources essential to their roles, maintaining a robust security posture.
- **Operational Benefits**: This configuration supports uninterrupted workflows, allowing developers and data scientists to work efficiently without connectivity issues. Furthermore, NetBird's centralized management of routing peers simplifies handling resources distributed across different networks, ensuring seamless connectivity and reducing complexity. Additionally, the process of creating new resources is streamlined, reducing administrative overhead and accelerating responses to frequent resource requests.
## Pre-requisites
@@ -227,4 +227,4 @@ Available Networks:
Resolved IPs: -
```
However, using your newly acquired knowledge, you can create access policies for each subdomain or organize data scientists into teams with varied permissions. With NetBird, the possibilities are endless.
However, using your newly acquired knowledge, you can create access policies for each subdomain or organize data scientists into teams with varied permissions. With NetBird, the possibilities are endless.

View File

@@ -8,7 +8,7 @@ Imagine a company that runs its accounting application at the subdomain `account
To this end, the company deployed [NetBird clients](https://docs.netbird.io/how-to/getting-started) on the devices used by both the finance and support teams. Complementing this, [NetBird routing peers](https://docs.netbird.io/how-to/networks-concept#routing-peers) were configured within the AWS VPC using [setup keys](https://docs.netbird.io/how-to/setup-keys-add-servers-to-network). This configuration guarantees a solid foundation for streamlined and secure connectivity.
More importantly, this setup allows the company to use NetBird's Networks and [Access Policies](https://docs.netbird.io/how-to/manage-network-access), to ensure that only authorized finance and support team members access the restricted website domain as follows:
More importantly, this setup allows the company to use NetBird's Networks and [Access Policies](https://docs.netbird.io/manage/access-control/manage-network-access), to ensure that only authorized finance and support team members access the restricted website domain as follows:
- **Finance Team**: HTTP and HTTPS access to the website frontend at `accounting.example.com` over ports `80` and `443`, respectively.
- **Support Team**: SSH access to backend resources at `example.com` over port `22`, enabling server management, troubleshooting, and support tasks.

View File

@@ -25,7 +25,7 @@ Before beginning this tutorial, ensure you have the following prerequisites in p
## Setting Up NetBird Access Policies for Team-Specific Permissions
[NetBird's Access Control Policies](https://docs.netbird.io/how-to/manage-network-access) let you implement a zero-trust security approach alongside Acronis Cyber Protect Cloud. They enable you to define precise permissions based on user groups and resource categories, ensuring that team members can only access what they need for their specific roles. This granular approach aligns with MSP requirements for managing multiple client environments with distinct access requirements.
[NetBird's Access Control Policies](https://docs.netbird.io/manage/access-control/manage-network-access) let you implement a zero-trust security approach alongside Acronis Cyber Protect Cloud. They enable you to define precise permissions based on user groups and resource categories, ensuring that team members can only access what they need for their specific roles. This granular approach aligns with MSP requirements for managing multiple client environments with distinct access requirements.
These policies work in tandem with Acronis RMM's monitoring and management capabilities. While Acronis monitors system compliance and maintains device health, NetBird enforces network-level access restrictions based on predefined group memberships.

View File

@@ -40,7 +40,7 @@ Here are a few links that might be handy as you venture further into NetBird:
- [Add users to your network](/how-to/add-users-to-your-network)
- [Require a peer approval from the administrator](/how-to/approve-peers)
- [Allow only managed devices in the network](/how-to/endpoint-detection-and-response)
- [Allow only managed devices in the network](/manage/access-control/endpoint-detection-and-response)
- [Use setup keys to automate NetBird deployments](/how-to/register-machines-using-setup-keys)
<p float="center" >

View File

@@ -37,7 +37,7 @@ To approve a peer, navigate to the [peers tab](https://app.netbird.io/peers) and
## Automate peer approval with EDR integrations
NetBird integrates with popular EDR solutions like [CrowdStrike](https://www.crowdstrike.com/) to automate peer approval
and allow only trusted devices to join the network.
Check the [EDR integrations](/how-to/endpoint-detection-and-response) guide for more information on how to enable this feature.
Check the [EDR integrations](/manage/access-control/endpoint-detection-and-response) guide for more information on how to enable this feature.
## Get started
<p float="center" >

View File

@@ -45,6 +45,6 @@ Let's say the current project is finished, and you no longer want members of the
![IdP Delete Group](/docs-static/img/how-to-guides/auto-offboard-users/TOZjFKC.png)
Once the changes synchronize in NetBird, users and their group memberships will be updated; therefore,
[network access associated with that group](https://docs.netbird.io/how-to/manage-network-access) will automatically be revoked.
[network access associated with that group](https://docs.netbird.io/manage/access-control/manage-network-access) will automatically be revoked.
![NetBird No Group](/docs-static/img/how-to-guides/auto-offboard-users/NKabmN6.png)

View File

@@ -69,7 +69,7 @@ Use this to see who can access resources in your routed [networks](/how-to/netwo
## Editing policies from the graph
- **Open editor:** Click an access control policy chip in any view to open the standard policy editor.
- **What you can change:** Use the editor to modify the usual policy fields as documented in [Access Control](/how-to/manage-network-access), including sources, destinations, protocols, ports, and posture checks.
- **What you can change:** Use the editor to modify the usual policy fields as documented in [Access Control](/manage/access-control/manage-network-access), including sources, destinations, protocols, ports, and posture checks.
- **Create vs edit:** You can edit existing policies from Control Center. Creating a new policy still happens in the Access Control section.
## Quick start
@@ -88,7 +88,7 @@ Use this to see who can access resources in your routed [networks](/how-to/netwo
## Related docs
- [Manage network access with Groups and Access Policies](/how-to/manage-network-access)
- [Apply posture checks to policies](/how-to/manage-posture-checks)
- [Manage network access with Groups and Access Policies](/manage/access-control/manage-network-access)
- [Apply posture checks to policies](/manage/access-control/posture-checks)
- [Networks and routing peers](/how-to/networks)
- [MSP portal overview](/how-to/msp-portal)

View File

@@ -245,12 +245,12 @@ If everything goes as expected, you will see your remote workload in NetBird's `
## 3. Setting Up NetBird's Access Control for Secure Data Transfer
NetBird's `Default` access control policy assigns all peers to the `All` group, enabling bidirectional access between devices and users. While this default setting allows immediate connectivity between your remote workload and on-premise database, it's recommended to implement stricter access controls. [NetBird Access Policies](https://docs.netbird.io/how-to/manage-network-access) enable you to limit connections to the on-premise instance, ensuring only authorized users or devices can access it, thus enhancing security.
NetBird's `Default` access control policy assigns all peers to the `All` group, enabling bidirectional access between devices and users. While this default setting allows immediate connectivity between your remote workload and on-premise database, it's recommended to implement stricter access controls. [NetBird Access Policies](https://docs.netbird.io/manage/access-control/manage-network-access) enable you to limit connections to the on-premise instance, ensuring only authorized users or devices can access it, thus enhancing security.
To create a new policy:
* Go to `Access Control > Policies`
* Click `Add Policy` to create a new policy. For more details on creating access policies, refer to [Managing Access with NetBird: Groups and Access Policies](https://docs.netbird.io/how-to/manage-network-access).
* Click `Add Policy` to create a new policy. For more details on creating access policies, refer to [Managing Access with NetBird: Groups and Access Policies](https://docs.netbird.io/manage/access-control/manage-network-access).
For this use case, we disabled the `Default` policy and created the following one:

View File

@@ -100,11 +100,11 @@ The final onboarding step introduces NetBird's powerful Access Control policies.
![NetBird policy disabled](/docs-static/img/getting-started/08_policy-disabled-example.jpeg)
1. By default, a policy is active that allows connections between all your devices. This is why the ping command in the previous step worked.
2. The wizard demonstrates this by allowing you to toggle the policy. If you disable the "Default Policy," the ping between your devices will immediately fail with a "Request timeout" error.
3. Re-enabling the policy instantly restores the connection. This gives you a basic understanding of how you can control traffic within your network. You can learn much more about policies [here](/how-to/manage-network-access).
3. Re-enabling the policy instantly restores the connection. This gives you a basic understanding of how you can control traffic within your network. You can learn much more about policies [here](/manage/access-control/manage-network-access).
4. Click Continue to finish.
![Policy Example](/docs-static/img/getting-started/09_policy-example.jpeg)
In the policy example above, we allowed _IT Admins_ port specific access to peers under the _AWS Servers_ group. Policies are a key building block to access in NetBird. You can learn more about the power of policies [here](https://docs.netbird.io/how-to/manage-network-access).
In the policy example above, we allowed _IT Admins_ port specific access to peers under the _AWS Servers_ group. Policies are a key building block to access in NetBird. You can learn more about the power of policies [here](https://docs.netbird.io/manage/access-control/manage-network-access).
<Note>
If you manage users and groups with your identity provider, you can provision and sync them with NetBird. Learn more [here](https://docs.netbird.io/how-to/idp-sync) including the supported platforms.
@@ -183,7 +183,7 @@ Click Go to Dashboard to access the main NetBird admin panel. From here, you can
* [Control Center](https://docs.netbird.io/how-to/control-center): Visualize your network topology and access relationships with an interactive graph.
* [Peers](https://docs.netbird.io/how-to/add-machines-to-your-network): View and manage all connected devices and their properties.
* [Setup Keys](https://docs.netbird.io/how-to/register-machines-using-setup-keys): Create and manage keys for adding new headless or ephemeral devices.
* [Access Control](https://docs.netbird.io/how-to/manage-network-access): Define granular firewall rules to control which peers can access what.
* [Access Control](https://docs.netbird.io/manage/access-control/manage-network-access): Define granular firewall rules to control which peers can access what.
* [Team](https://docs.netbird.io/how-to/add-users-to-your-network): Manage users and create groups for easier policy management.
You are now ready to explore the full capabilities of NetBird.

View File

@@ -15,7 +15,7 @@ and automatically provisioning users and groups. This integration ensures that c
synchronized from your identity provider to NetBird, granting appropriate network access to new users and immediately
revoking access for departing employees.
NetBird allows you to use synchronized groups to create [access control policies](/how-to/manage-network-access#creating-policies),
NetBird allows you to use synchronized groups to create [access control policies](/manage/access-control/manage-network-access#creating-policies),
or update network configurations like [DNS](/how-to/manage-dns-in-your-network#distribution-groups),
eliminating the need for manual grouping.

View File

@@ -26,7 +26,7 @@ Before beginning this tutorial, ensure you have the following prerequisites in p
## Setting Up NetBird Access Policies for Team-Specific Permissions
[NetBird's Access Control Policies](https://docs.netbird.io/how-to/manage-network-access) provide the foundation for implementing a zero-trust architecture with Intune. They enable you to define precise permissions based on user groups and resource categories. This ensures that team members can only access what they need for their specific roles.
[NetBird's Access Control Policies](https://docs.netbird.io/manage/access-control/manage-network-access) provide the foundation for implementing a zero-trust architecture with Intune. They enable you to define precise permissions based on user groups and resource categories. This ensures that team members can only access what they need for their specific roles.
These policies work in tandem with Intune's device compliance mechanisms, creating a powerful security layer where identity and device posture determine access rights to the network.

View File

@@ -29,7 +29,7 @@ These requirements are essential for successfully implementing NetBird-Jamf Pro
## Setting Up NetBird Access Policies for Team-Specific Permissions
NetBird's [Access Control Policies](https://docs.netbird.io/how-to/manage-network-access) are essential to this integration, allowing you to define and enforce specific permissions for different user groups. This ensures that team members can only access the resources necessary for their roles.
NetBird's [Access Control Policies](https://docs.netbird.io/manage/access-control/manage-network-access) are essential to this integration, allowing you to define and enforce specific permissions for different user groups. This ensures that team members can only access the resources necessary for their roles.
For this tutorial, we'll create a policy that allows the `Support` team to access the `Servers` group:

View File

@@ -20,7 +20,7 @@ To successfully integrate NetBird with Kandji MDM, ensure you have the following
## Configuring NetBird Access Policies for Team-Specific Permissions
NetBird plays a crucial role in this integration by providing granular access control through its [Access Control Policies](https://docs.netbird.io/how-to/manage-network-access). These features allow you to define and enforce specific permissions for different user groups, ensuring that team members can only access the resources necessary for their roles.
NetBird plays a crucial role in this integration by providing granular access control through its [Access Control Policies](https://docs.netbird.io/manage/access-control/manage-network-access). These features allow you to define and enforce specific permissions for different user groups, ensuring that team members can only access the resources necessary for their roles.
For instance, let's suppose you want to create a policy that allows the `Support` team to access the `Servers` group:

View File

@@ -18,7 +18,7 @@ Starting [v0.11.0](https://github.com/netbirdio/netbird/releases), NetBird autom
to each peer in a private `netbird.cloud` space that can be used to access the machines. E.g., `my-server.netbird.cloud`.
Besides accessing machines by their domain names, you can configure NetBird to use your private nameservers,
control what nameservers a specific [peer group](/how-to/manage-network-access#groups) should use, and set up split DNS.
control what nameservers a specific [peer group](/manage/access-control/manage-network-access#groups) should use, and set up split DNS.
<Note>
Nameservers feature is available in NetBird [v0.11.0](https://github.com/netbirdio/netbird/releases) or later on both

View File

@@ -182,5 +182,5 @@ You should see all the users and groups from your Microsoft Entra ID environment
![NetBird Checking Integration](/docs-static/img/how-to-guides/microsoft-entra-id-sync/qlNlfgV.png)
You can now proceed to configure [access control policies](/how-to/manage-network-access#creating-policies) using the synchronized groups to allow or deny access to the
You can now proceed to configure [access control policies](/manage/access-control/manage-network-access#creating-policies) using the synchronized groups to allow or deny access to the
synchronized users.

View File

@@ -104,7 +104,7 @@ On a technical level the feature works as follows:
## Manage access to resources
To manage access to resources, you can assign them to groups and create [access control policies](/how-to/manage-network-access#creating-policies) to define which peers can access them.
To manage access to resources, you can assign them to groups and create [access control policies](/manage/access-control/manage-network-access#creating-policies) to define which peers can access them.
See the image below with an example resource `CRM`:
<p>
<img src="/docs-static/img/how-to-guides/networks/resources-2.png" alt="resource-group" className="imagewrapper"/>

View File

@@ -37,13 +37,13 @@ With these prerequisites in place, you're ready to simulate granting network acc
## 1. Setting Up NetBird's Access Control Policies For Enhanced Security
Before onboarding remote workers, ensure your organization has appropriate [access control policies](/how-to/manage-network-access) in place. Adhering to zero-trust principles, create or modify policies to grant new users access only to necessary resources.
Before onboarding remote workers, ensure your organization has appropriate [access control policies](/manage/access-control/manage-network-access) in place. Adhering to zero-trust principles, create or modify policies to grant new users access only to necessary resources.
Navigate to `Access Control > Policies` in the NetBird admin console, then click `Add Policy` or edit an existing one to define these restrictions. Here's a sample policy that grant any member of the `Freelancers` group access to the resources in the group `On-Premise-DB`.
![NetBird Freelancer Access Control Policy](/docs-static/img/how-to-guides/peer-approval-for-remote-worker-access/peer-0-01.png)
If necessary, you can also set [posture checks](/how-to/manage-posture-checks) for this policy.
If necessary, you can also set [posture checks](/manage/access-control/posture-checks) for this policy.
![NetBird Freelancer Posture Check](/docs-static/img/how-to-guides/peer-approval-for-remote-worker-access/peer-0-02.png)
@@ -139,6 +139,6 @@ To activate this feature, navigate to `Integrations > EDR` and activate the Crow
![NetBird EDR Integration](/docs-static/img/how-to-guides/peer-approval-for-remote-worker-access/peer-a-18.png)
For more information regarding NetBird's EDR integration, refer to the [documentation](/how-to/endpoint-detection-and-response)
For more information regarding NetBird's EDR integration, refer to the [documentation](/manage/access-control/endpoint-detection-and-response)

View File

@@ -60,7 +60,7 @@ If you add multiple peers with the same labels, they became part of a DNS round-
## Peer Auto-grouping
NetBird offers a powerful [access control feature](/how-to/manage-network-access) that allows easy access management of your resources.
NetBird offers a powerful [access control feature](/manage/access-control/manage-network-access) that allows easy access management of your resources.
In a basic scenario, you would create multiple groups of peers and create access rules to define what groups can access each other.
Adding peers to groups might become time-consuming in large networks with dozens of machines.

View File

@@ -106,7 +106,7 @@ With both peers now connected to NetBird, the next step is to configure access c
* In NetBird's left menu, navigate to `Access Control > Policies`
* Click `Add Policy` to create a new one.
NetBird offers a range of options for peer access control. For comprehensive details on configuring groups and access policies, refer to the official documentation: [Managing Access with NetBird: Groups and Access Policies](/how-to/manage-network-access).
NetBird offers a range of options for peer access control. For comprehensive details on configuring groups and access policies, refer to the official documentation: [Managing Access with NetBird: Groups and Access Policies](/manage/access-control/manage-network-access).
For this specific use case, we've implemented a simple access policy:

View File

@@ -193,7 +193,7 @@ Alternatively, you can go to `http://VM_NETBIRD_DOMAIN:8080` using your browser:
![NetBird Welcome Page](/docs-static/img/how-to-guides/setup-keys-add-servers-to-network/setup-keys-add-server-04.png)
Keep in mind that this tutorial used the default `All` group for simplicity. However, implementing [NetBird's Access Policy](https://docs.netbird.io/how-to/manage-network-access) to restrict peer-to-peer connections to specific user groups is a best practice for gaining granular control over resource access, thus improving your network's overall security posture in various scenarios.
Keep in mind that this tutorial used the default `All` group for simplicity. However, implementing [NetBird's Access Policy](https://docs.netbird.io/manage/access-control/manage-network-access) to restrict peer-to-peer connections to specific user groups is a best practice for gaining granular control over resource access, thus improving your network's overall security posture in various scenarios.
## Optional: Automating SSH Access to Your VM

View File

@@ -28,7 +28,7 @@ that describe how NetBird logs traffic events for different types of connections
When two peers are connected directly (p2p), NetBird captures and logs the traffic events for that connection on both peers.
For example, if a user accessed an internal CRM server from their laptop via a browser and port 443, NetBird would log the traffic events for that
connection on both the user's machine and the CRM server. If the connection was blocked, such as when there is a
[policy](/how-to/manage-network-access#managing-policies) that restricts access to the CRM server,
[policy](/manage/access-control/manage-network-access#managing-policies) that restricts access to the CRM server,
NetBird would log the blocked event on the peer that refused the connection.
<p>

View File

@@ -38,21 +38,21 @@ Before you start creating and configuring a CrowdStrike integration, ensure that
- Navigate to the [Integrations &raquo; 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/how-to-guides/crowdstrike-integration.png" alt="event-streaming-integration" className="imagewrapper-big"/>
<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/how-to-guides/crowdstrike-region.png" alt="crowdstrike-region" className="imagewrapper"/>
<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/how-to-guides/crowdstrike-credentials.png" alt="crowdstrike-credentials" className="imagewrapper"/>
<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/how-to-guides/crowdstrike-groups-zta.png" alt="crowdstrike-groups-zta" className="imagewrapper"/>
<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>
@@ -66,7 +66,7 @@ Before you start creating and configuring a CrowdStrike integration, ensure that
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/how-to-guides/edr-approval-required.png" alt="edr-approval-required" className="imagewrapper-big"/>
<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:

View File

@@ -1,6 +1,6 @@
# Integrate NetBird with MDM & EDR Platforms
![Endpoint Detection and Response](/docs-static/img/how-to-guides/endpoint-detection-and-response/edr-integrations.png)
![Endpoint Detection and Response](/docs-static/img/manage/access-control/endpoint-detection-and-response/edr-integrations.png)
## What is EDR and MDM?
Endpoint Detection and Response (EDR) is a cybersecurity technology designed to help organizations detect, investigate,
@@ -35,6 +35,6 @@ the checks to apply.
NetBird integrates with the following EDR platforms:
* [CrowdStrike Falcon](/how-to/crowdstrike-edr)
* [Microsoft Intune](/how-to/intune-mdm)
* [SentinelOne Singularity](/how-to/sentinelone-edr)
* [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)

View File

@@ -21,7 +21,7 @@ In this guide, you'll learn how to integrate NetBird with Microsoft Intune and c
- Navigate to the [Integrations &raquo; 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/how-to-guides/intune-mdm/getting-started.png" alt="NetBird Get Started Intune MDM" className="imagewrapper-big"/>
<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
@@ -40,7 +40,7 @@ To check your permissions:
* 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.
![Intune Roles](/docs-static/img/how-to-guides/microsoft-entra-id-sync/lDyaAeV.png)
![Intune Roles](/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/lDyaAeV.png)
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.
@@ -53,21 +53,21 @@ A new wizard screen will appear, offering step-by-step instructions for creating
* Name
* Account Type
![NetBird Create Application](/docs-static/img/how-to-guides/intune-mdm/create-app.png)
![NetBird Create Application](/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/create-app.png)
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:
![Intune App Registration](/docs-static/img/how-to-guides/microsoft-entra-id-sync/Yxxktk6.png)
![Intune App Registration](/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/Yxxktk6.png)
Fill in the required information:
![Intune Register an App](/docs-static/img/how-to-guides/intune-mdm/register-app.png)
![Intune Register an App](/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/register-app.png)
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:
![Intune App Registered](/docs-static/img/how-to-guides/microsoft-entra-id-sync/7WYZMW6.png)
![Intune App Registered](/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/7WYZMW6.png)
Copy and securely store the generated `Application (client) ID` and `Directory (tenant) ID` as you will need them shortly.
@@ -75,23 +75,23 @@ Copy and securely store the generated `Application (client) ID` and `Directory (
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.
![NetBird Add API Permissions](/docs-static/img/how-to-guides/intune-mdm/api-permissions.png)
![NetBird Add API Permissions](/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/api-permissions.png)
Back to Azure, in the `App registrations` screen, click on `Manage` in the left menu to expand it and then click on `API permissions`:
![Intune API Permissions](/docs-static/img/how-to-guides/microsoft-entra-id-sync/V0aRf7f.png)
![Intune API Permissions](/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/V0aRf7f.png)
Look for the `+ Add a permission` button, located near the top of the permissions list and click on it.
![Intune API Permissions Screen](/docs-static/img/how-to-guides/microsoft-entra-id-sync/Qy9lDMF.png)
![Intune API Permissions Screen](/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/Qy9lDMF.png)
A new pop-up window will appear, asking you to select an API. Click on `Microsoft Graph`.
![Intune Microsoft Graph](/docs-static/img/how-to-guides/microsoft-entra-id-sync/tP7WqXO.png)
![Intune Microsoft Graph](/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/tP7WqXO.png)
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.
![Intune Request API Permissions](/docs-static/img/how-to-guides/microsoft-entra-id-sync/zSkSGAm.png)
![Intune Request API Permissions](/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/zSkSGAm.png)
To assign user permissions:
@@ -99,13 +99,13 @@ To assign user permissions:
* 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.
![Intune UserReadAll](/docs-static/img/how-to-guides/intune-mdm/device-permissions.png)
![Intune UserReadAll](/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/device-permissions.png)
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:
![Intune API Permissions Warnings](/docs-static/img/how-to-guides/intune-mdm/grant-permissions.png)
![Intune API Permissions Warnings](/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/grant-permissions.png)
Locate the `Grant admin consent for [Your Organization Name]` button (youll find it next to `+Add a permission` button). Click on it to grant the required permissions.
@@ -113,21 +113,21 @@ A confirmation dialog will appear, asking you to verify this action. Review the
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:
![Intune API Permissions Granted](/docs-static/img/how-to-guides/intune-mdm/granted-permissions.png)
![Intune API Permissions Granted](/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/granted-permissions.png)
## 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.
![NetBird Generate Client Secret](/docs-static/img/how-to-guides/intune-mdm/client-secret.png)
![NetBird Generate Client Secret](/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/client-secret.png)
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.
![EntraID Add a Client Secret](/docs-static/img/how-to-guides/microsoft-entra-id-sync/WIercn5.png)
![EntraID Add a Client Secret](/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/WIercn5.png)
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.
![EntraID Client Secret Value](/docs-static/img/how-to-guides/microsoft-entra-id-sync/LimVmGI.png)
![EntraID Client Secret Value](/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/LimVmGI.png)
## Enter Application ID and Directory ID in NetBird
@@ -135,14 +135,14 @@ Paste the secret `Value` from the previous step into NetBird and click the `Cont
Paste the values and click the `Continue →` button.
![NetBird Application ID and Directory](/docs-static/img/how-to-guides/intune-mdm/client-id.png)
![NetBird Application ID and Directory](/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/client-id.png)
## Choose Groups to require Intune Agent
At this stage, specify one or more NerBird groups to which the check should apply. The check will require the peer to have a running Intune agent installed.
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.
![Intune Groups](/docs-static/img/how-to-guides/intune-mdm/groups.png)
![Intune Groups](/docs-static/img/manage/access-control/endpoint-detection-and-response/intune-mdm/groups.png)
<Note>
The MDM check will apply only to machines in the selected groups and will require a running Intune agent.
@@ -155,7 +155,7 @@ Peers that have the Intune agent installed and are compliant will be granted acc
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/how-to-guides/edr-approval-required.png" alt="edr-approval-required" className="imagewrapper-big"/>
<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
@@ -163,5 +163,5 @@ with a `Approval required` mark in the peers list and won't be able to access th
- 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.
- 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.

View File

@@ -50,25 +50,25 @@ Treat the API token securely and store it safely. You will need both the console
- Navigate to the [Integrations &raquo; 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/how-to-guides/endpoint-detection-and-response/sentinelone/getting-started.png" alt="SentinelOne integration getting started" className="imagewrapper-big"/>
<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/how-to-guides/endpoint-detection-and-response/sentinelone/console-config.png" alt="SentinelOne console configuration" className="imagewrapper-big"/>
<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/how-to-guides/endpoint-detection-and-response/sentinelone/service-user.png" alt="SentinelOne service user configuration" className="imagewrapper-big"/>
<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/how-to-guides/endpoint-detection-and-response/sentinelone/group-config.png" alt="SentinelOne group configuration" className="imagewrapper-big"/>
<img src="/docs-static/img/manage/access-control/endpoint-detection-and-response/sentinelone/group-config.png" alt="SentinelOne group configuration" className="imagewrapper-big"/>
</p>
@@ -87,14 +87,14 @@ Treat the API token securely and store it safely. You will need both the console
- **Latest Agent Version**: Requires the SentinelOne agent to be running the most current version.
<p>
<img src="/docs-static/img/how-to-guides/endpoint-detection-and-response/sentinelone/compliance-config.png" alt="edr-integrations" className="imagewrapper-big"/>
<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/how-to-guides/endpoint-detection-and-response/sentinelone/sync-config.png" alt="edr-integrations" className="imagewrapper-big"/>
<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
@@ -104,7 +104,7 @@ Treat the API token securely and store it safely. You will need both the console
the network until they have the agent installed and satisfy all the specified security requirements.
<p>
<img src="/docs-static/img/how-to-guides/endpoint-detection-and-response/sentinelone/edr-approval-required.png" alt="edr-approval-required" className="imagewrapper-big"/>
<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>

View 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 dont 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 NetBirds 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.

View File

@@ -1,6 +1,5 @@
import {Note} from "../../components/mdx";
# 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
@@ -86,7 +85,7 @@ Make sure to set traffic direction only when TCP or UDP protocols are selected.
<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](/how-to/manage-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.
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>

View File

@@ -1,9 +1,7 @@
# 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/how-to/manage-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](/how-to/manage-posture-checks#peer-network-range) posture check with a block action.
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`.
@@ -15,14 +13,14 @@ To create a Posture Check, navigate to the `Access Control -> Posture Checks` se
Select `Peer Network Range`.
<p>
<img src="/docs-static/img/how-to-guides/posture-check-new-block-network-range.png" alt="high-level-dia" className="imagewrapper"/>
<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/how-to-guides/posture-check-block-network-range.png" alt="high-level-dia" className="imagewrapper"/>
<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”.
@@ -39,13 +37,13 @@ Choose `UDP` for the protocol and type `1`on Ports. Click `Continue`.
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/how-to-guides/policy-office-subnet-with-posturecheck.png" alt="high-level-dia" className="imagewrapper"/>
<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/how-to-guides/policy-with-network-posturecheck-added.png" alt="high-level-dia" className="imagewrapper"/>
<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`.
@@ -60,15 +58,15 @@ which is a member of the group `route-nodes`, this way, the policy we just creat
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/how-to-guides/create-route-with-posturecheck.png" alt="high-level-dia" className="imagewrapper"/>
<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/how-to-guides/distribute-to-groups-posturechecks.png" alt="high-level-dia" className="imagewrapper"/>
<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/how-to-guides/route-office-subnet-posturecheck.png" alt="high-level-dia" className="imagewrapper"/>
<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`.
@@ -76,26 +74,26 @@ Now that we have created the Posture Check, the Policy, and the Network Route, w
#### 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/how-to-guides/wifi-inside-office-subnet.png" alt="high-level-dia" className="imagewrapper"/>
<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/how-to-guides/netbird-routes-list-local.png" alt="high-level-dia" className="imagewrapper"/>
<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/how-to-guides/netstat-routes-grep-local.png" alt="high-level-dia" className="imagewrapper"/>
<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/how-to-guides/netbird-routes-list-external.png" alt="high-level-dia" className="imagewrapper"/>
<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/how-to-guides/netstat-routes-grep-external.png" alt="high-level-dia" className="imagewrapper"/>
<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`).

View File

@@ -1,29 +1,4 @@
# NetBird Posture Checks: Access Control for Modern Organizations
Today, organizations face the critical challenge of maintaining robust access control across their IT infrastructure. As networks grow more complex and threats become increasingly sophisticated, traditional access control methods often fall short, leaving businesses vulnerable to security breaches and operational inefficiencies.
Key challenges include:
* Dynamic infrastructures
* Need for granular control
* Scalability issues
NetBird's Posture Checks feature offers:
* Adaptive, context-aware access
* Highly granular policies
* Effortless scalability
This solution enhances security and efficiency by:
* Reducing unauthorized access risk
* Automating policy-based control
* Enabling business agility
Let's delve into the details of how [NetBird's Posture Checks](https://docs.netbird.io/how-to/manage-posture-checks) feature transforms access control, making it more secure, efficient, and adaptable for modern enterprises.
## Understanding NetBird Posture Checks
# 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.
@@ -43,35 +18,35 @@ 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.
![NetBird Posture Checks](/docs-static/img/how-to-guides/posture-checks/posture-checks-01.png)
![NetBird Posture Checks](/docs-static/img/manage/access-control/posture-checks/posture-checks-01.png)
A pop-up window will open with two tabs: `Checks` and `Name & Description`.
![Create Posture Check](/docs-static/img/how-to-guides/posture-checks/posture-checks-02.png)
![Create Posture Check](/docs-static/img/manage/access-control/posture-checks/posture-checks-02.png)
From here, you can [manage access with posture checks](https://docs.netbird.io/how-to/manage-posture-checks) based on several aspects:
From here, you can manage access with posture checks based on several aspects:
#### NetBird Client Version
### 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.
![NetBird Client Version Posture Check](/docs-static/img/how-to-guides/posture-checks/posture-checks-03.png)
![NetBird Client Version Posture Check](/docs-static/img/manage/access-control/posture-checks/posture-checks-03.png)
#### Country and Region
### 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..
![Country and Region Posture Check](/docs-static/img/how-to-guides/posture-checks/posture-checks-04.png)
![Country and Region Posture Check](/docs-static/img/manage/access-control/posture-checks/posture-checks-04.png)
<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.
![Peer Network Range Posture Check](/docs-static/img/how-to-guides/posture-checks/posture-checks-05.png)
![Peer Network Range Posture Check](/docs-static/img/manage/access-control/posture-checks/posture-checks-05.png)
#### Operating System
### Operating System
Restrict access based on the connecting device's OS, ensuring only approved and potentially more secure operating systems can connect.
![Operating System Posture Check](/docs-static/img/how-to-guides/posture-checks/posture-checks-06.png)
![Operating System Posture Check](/docs-static/img/manage/access-control/posture-checks/posture-checks-06.png)
<Note>
The Operating System Check requires NetBird version [0.26.0](https://github.com/netbirdio/netbird/releases) or newer.
</Note>
@@ -89,45 +64,45 @@ Below are some examples of OS versions for each operating system:
* Windows 11, version 23H2: `10.0.22631`
* Windows Server 2022, Version 21H2: `10.0.20348`
#### Process
### 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.
![Process Posture Check](/docs-static/img/how-to-guides/posture-checks/posture-checks-07.png)
![Process Posture Check](/docs-static/img/manage/access-control/posture-checks/posture-checks-07.png)
#### Naming and saving
## 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.
![Name your Posture Check](/docs-static/img/how-to-guides/posture-checks/posture-checks-08.png)
![Name your Posture Check](/docs-static/img/manage/access-control/posture-checks/posture-checks-08.png)
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.
![New Posture Check](/docs-static/img/how-to-guides/posture-checks/posture-checks-09.png)
![New Posture Check](/docs-static/img/manage/access-control/posture-checks/posture-checks-09.png)
#### Applying Posture Checks to Access Control Policies
## Applying Posture Checks to Access Control Policies
To apply a posture check:
* [Create or edit an access control policy](https://docs.netbird.io/how-to/manage-network-access).
* [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.
![Add Posture Check to Access Control Policy](/docs-static/img/how-to-guides/posture-checks/posture-checks-10.png)
![Add Posture Check to Access Control Policy](/docs-static/img/manage/access-control/posture-checks/posture-checks-10.png)
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.
![Access Control Policies Dashboard](/docs-static/img/how-to-guides/posture-checks/posture-checks-11.png)
![Access Control Policies Dashboard](/docs-static/img/manage/access-control/posture-checks/posture-checks-11.png)
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.
![Posture Checks Dashboard](/docs-static/img/how-to-guides/posture-checks/posture-checks-12.png)
![Posture Checks Dashboard](/docs-static/img/manage/access-control/posture-checks/posture-checks-12.png)
Following these steps, you can effectively implement and manage NetBird's Posture Checks, significantly enhancing your network's security posture.
## Get started
## Get started with NetBird
<p float="center" >
<Button name="button" className="button-5" onClick={() => window.open("https://netbird.io/pricing")}>Use NetBird</Button>
</p>

View File

@@ -37,7 +37,7 @@ some additional features that are targeted at business customers and help with n
- **[Users and groups provisioning](/how-to/idp-sync)** from your identity provider (IdP).
- **[Traffic events logging](/how-to/traffic-events-logging)** of connections to internal resources for audit and analysis.
- **[Event streaming](/how-to/activity-event-streaming)** to 3rd party platforms and SIEM systems.
- **[Integrations with EDR](/how-to/endpoint-detection-and-response)** like CrowdStrike and others.
- **[Integrations with EDR](/manage/access-control/endpoint-detection-and-response)** like CrowdStrike and others.
- **[Peer approval](/how-to/approve-peers)** to join the network.
- **[User invites](/how-to/add-users-to-your-network#direct-user-invites)**.
- **[MSP functionality](/how-to/msp-portal)** for managing multiple tenant networks from a single account.