mirror of
https://github.com/netbirdio/docs.git
synced 2026-08-28 10:41:27 +02:00
Navigation cleanup: MDM deployment under Peers, purge stale tutorials, MSP portal refresh (#906)
* docs: move MDM deployment guides under Manage > Peers
The five fleet-deployment guides (GPO, macOS .pkg, Jamf Pro, Kandji,
Intune) lived under Integrations, but nothing in them integrates with
NetBird's platform — they are peer onboarding at scale, which lives
under Peers. The label also collided with Access Control's
'Integrate MDM & EDR', which uses MDM in the opposite sense.
- Move pages from /manage/integrations/mdm-deployment/ to
/manage/peers/mdm-deployment/ with a permanent wildcard redirect
- Re-point legacy /how-to redirects directly at the new paths
- Move the nav group under Peers as 'MDM Deployment'; remove the
now-empty Integrations group
- Update internal links
* docs: link full GPO deployment guide from MDM integration page
* docs: show setup-key secret wiring and replica naming for k8s routing peers
Fold the two verified-novel bits from the Access Infrastructure
autoscaling tutorial before purging it:
- Replace the 'use a secret' Note with the actual kubectl create
secret + secretKeyRef wiring (matches what the NetBird operator
injects for routing peers)
- In the HA section, note that removing the static NB_HOSTNAME lets
each replica register under its pod name (client falls back to
os.Hostname(), which is the pod name in Kubernetes)
* docs: purge redundant Access Infrastructure tutorials
The four pages under Manage > Peers > Access Infrastructure were
2024-era SEO tutorials that duplicated canonical feature docs and
carried outdated claims (pre-rewrite SSH model without the built-in
SSH server, a Docker section that never actually enrolls the
container with a setup key, CrowdStrike presented as the only EDR
integration, stale v0.29 output and vintage-UI screenshots).
Cross-checked each page against its canonical counterpart; nothing
novel remained (the two useful Kubernetes snippets were folded into
the routing-peers use case in the previous commit).
- Delete the four pages and their screenshot directory
- Remove the Access Infrastructure nav group
- Redirect each URL to its canonical replacement:
secure-remote-webserver-access -> /manage/peers/ssh
setup-keys-add-servers-to-network -> /manage/peers/register-machines-using-setup-keys
access-internal-resources-from-autoscaled-environments -> /use-cases/kubernetes
peer-approval-for-remote-worker-access -> /manage/peers/approve-peers
- Re-point the legacy /how-to redirects at the same targets to avoid
redirect chains
* docs: reorder Peers nav into enrollment, approval, day-2 flow
Group the five enrollment methods first (Add Peers, Setup Keys,
Bootstrap via Config File, MDM Deployment, Browser Client), then the
Approve Peers admission gate, then running-peer features (SSH, Lazy
Connections, Remote Jobs) and Auto Update last. Approve Peers
previously sat between two enrollment pages.
* docs: cross-link DNS aliases and internal DNS pages, fix tutorial inaccuracies
The two pages solve adjacent problems (NetBird-hosted records vs
forwarding to existing internal DNS) but never pointed at each other.
Add a which-page-do-I-need Note to each.
Also fix defects in the DNS Aliases tutorial found while cross-checking
it against the Custom Zones reference and dashboard source:
- 'Keep this enabled' implied search domain is on by default; it is
off by default (DNSZoneModal.tsx: enable_search_domain ?? false)
- Step 3 said 'wildcard resource' but the steps add exact-name domain
resources
- Wrong alt text ('Delete DNS Zone') on the zone-config screenshot
- Add missing meta description and a link to the Custom Zones
reference
* docs: align MSP portal page with 2026 partner program, rename For Partners nav
Cross-checked the MSP portal page against the 2026 MSP/MSSP Partner
Program document:
- Point the application link at netbird.io/use-cases/msp (the program's
canonical page) instead of a demo-form URL displayed as netbird.io/msp
- State tenant plan options (Team or Business) and the post-trial
minimum (Team plan with one user)
- Mention CSV/PDF usage export alongside the API
- Clarify the 3-day trial for existing accounts brought in as tenants:
it is a window to subscribe the tenant under the MSP account
- Add a subtle msp@netbird.io contact line at the bottom
Also rename the For Partners nav entries by deliverable instead of
audience (the section header already says who it's for): MSP Portal,
Distributor Portal, Deploy with Acronis.
* docs: update CLAUDE.md for agent-network, proxy.js, and tooling gaps
Audited every claim against the current repo. Stack, routing, security,
and convention claims all still hold; four gaps had accumulated:
- Add agent-network/ to the content structure list
- Document src/proxy.js in URL Routing: /api data requests must be
rewritten there because the config rewrite loses data-request context
on client-side navigation (Next.js #39669) and strips pageProps
- Add npm run lint:mdx; note npm run gen requires a Go toolchain
- Note fenced mermaid code blocks render as diagrams
* docs: address review findings on PR #906
- Move the MDM deployment screenshot directories to match the new page
paths; the URL rewrite had updated MDX image references without
moving the assets, breaking all Intune/Jamf/Kandji images
- Normalize pre-existing double slashes in Jamf and Kandji image URLs
- Align the routing-peers secret example with bootstrap-via-config-file
(same secret name, so both now use the NB_SETUP_KEY data key)
- DNS aliases: include the routing peer's group in the zone's
distribution groups. Verified in client source: the DNS route
interceptor (priority 100) outranks local zone records (priority 75)
and never falls through, so clients forward routed-domain queries to
the routing peer, which must receive the zone to answer
This commit is contained in:
Jack Carter
@@ -90,7 +90,6 @@ export const docsNavigation = [
|
||||
title: 'Add Peers',
|
||||
href: '/manage/peers/add-machines-to-your-network',
|
||||
},
|
||||
{ title: 'Approve Peers', href: '/manage/peers/approve-peers' },
|
||||
{
|
||||
title: 'Setup Keys',
|
||||
href: '/manage/peers/register-machines-using-setup-keys',
|
||||
@@ -99,6 +98,32 @@ export const docsNavigation = [
|
||||
title: 'Bootstrap via Config File',
|
||||
href: '/manage/peers/bootstrap-via-config-file',
|
||||
},
|
||||
{
|
||||
title: 'MDM Deployment',
|
||||
isOpen: false,
|
||||
links: [
|
||||
{
|
||||
title: 'Deploy with Group Policy (GPO)',
|
||||
href: '/manage/peers/mdm-deployment/windows-gpo-deployment',
|
||||
},
|
||||
{
|
||||
title: 'macOS CLI-Only .pkg',
|
||||
href: '/manage/peers/mdm-deployment/macos-cli-pkg-deployment',
|
||||
},
|
||||
{
|
||||
title: 'Deploy with Jamf Pro',
|
||||
href: '/manage/peers/mdm-deployment/jamf-pro-netbird-integration',
|
||||
},
|
||||
{
|
||||
title: 'Deploy with Kandji',
|
||||
href: '/manage/peers/mdm-deployment/kandji-netbird-integration',
|
||||
},
|
||||
{
|
||||
title: 'Deploy with Intune',
|
||||
href: '/manage/peers/mdm-deployment/intune-netbird-integration',
|
||||
},
|
||||
],
|
||||
},
|
||||
{
|
||||
title: 'Browser Client',
|
||||
isOpen: false,
|
||||
@@ -110,31 +135,10 @@ export const docsNavigation = [
|
||||
},
|
||||
],
|
||||
},
|
||||
{ title: 'Approve Peers', href: '/manage/peers/approve-peers' },
|
||||
{ title: 'SSH', href: '/manage/peers/ssh' },
|
||||
{ title: 'Lazy Connections', href: '/manage/peers/lazy-connection' },
|
||||
{ title: 'Remote Jobs', href: '/manage/peers/remote-jobs' },
|
||||
{
|
||||
title: 'Access Infrastructure',
|
||||
isOpen: true,
|
||||
links: [
|
||||
{
|
||||
title: 'Access Remote Webserver',
|
||||
href: '/manage/peers/access-infrastructure/secure-remote-webserver-access',
|
||||
},
|
||||
{
|
||||
title: 'Add Servers to the Network',
|
||||
href: '/manage/peers/access-infrastructure/setup-keys-add-servers-to-network',
|
||||
},
|
||||
{
|
||||
title: 'Access from Kubernetes',
|
||||
href: '/manage/peers/access-infrastructure/access-internal-resources-from-autoscaled-environments',
|
||||
},
|
||||
{
|
||||
title: 'Peer Approval for Remote Access',
|
||||
href: '/manage/peers/access-infrastructure/peer-approval-for-remote-worker-access',
|
||||
},
|
||||
],
|
||||
},
|
||||
{ title: 'Auto Update', href: '/manage/peers/auto-update' },
|
||||
],
|
||||
},
|
||||
@@ -418,39 +422,6 @@ export const docsNavigation = [
|
||||
{ title: 'Delete Account', href: '/manage/settings/delete-account' },
|
||||
],
|
||||
},
|
||||
{
|
||||
title: 'Integrations',
|
||||
isOpen: false,
|
||||
links: [
|
||||
{
|
||||
title: 'MDM for Deployment',
|
||||
isOpen: true,
|
||||
links: [
|
||||
{
|
||||
title: 'Deploy with Group Policy (GPO)',
|
||||
href: '/manage/integrations/mdm-deployment/windows-gpo-deployment',
|
||||
},
|
||||
{
|
||||
title: 'macOS CLI-Only .pkg',
|
||||
href: '/manage/integrations/mdm-deployment/macos-cli-pkg-deployment',
|
||||
},
|
||||
{
|
||||
title: 'Deploy with Jamf Pro',
|
||||
href: '/manage/integrations/mdm-deployment/jamf-pro-netbird-integration',
|
||||
},
|
||||
{
|
||||
title: 'Deploy with Kandji',
|
||||
href: '/manage/integrations/mdm-deployment/kandji-netbird-integration',
|
||||
},
|
||||
{
|
||||
title: 'Deploy with Intune',
|
||||
href: '/manage/integrations/mdm-deployment/intune-netbird-integration',
|
||||
},
|
||||
],
|
||||
},
|
||||
],
|
||||
},
|
||||
|
||||
{
|
||||
title: 'Public API',
|
||||
isOpen: false,
|
||||
@@ -461,15 +432,15 @@ export const docsNavigation = [
|
||||
isOpen: false,
|
||||
links: [
|
||||
{
|
||||
title: 'Managed Service Providers',
|
||||
title: 'MSP Portal',
|
||||
href: '/manage/for-partners/msp-portal',
|
||||
},
|
||||
{
|
||||
title: 'Distributors',
|
||||
title: 'Distributor Portal',
|
||||
href: '/manage/for-partners/distributor-portal',
|
||||
},
|
||||
{
|
||||
title: 'Acronis NetBird integration',
|
||||
title: 'Deploy with Acronis',
|
||||
href: '/manage/for-partners/acronis-integration',
|
||||
},
|
||||
],
|
||||
|
||||
@@ -94,7 +94,7 @@ The settings page uses a tabbed layout that groups options by what they control.
|
||||
|
||||
## MDM-Driven UI
|
||||
|
||||
If you roll out NetBird through MDM, the app reads the policy in effect on the device and adjusts itself to match, so users only see the options they are allowed to use. For deploying NetBird through an MDM provider, see the [MDM deployment guides](/manage/integrations/mdm-deployment/intune-netbird-integration).
|
||||
If you roll out NetBird through MDM, the app reads the policy in effect on the device and adjusts itself to match, so users only see the options they are allowed to use. For deploying NetBird through an MDM provider, see the [MDM deployment guides](/manage/peers/mdm-deployment/intune-netbird-integration).
|
||||
|
||||
* **Hide whole views.** `disableAdvancedView` hides the Advanced view of the main window, so managed users only see the compact one.
|
||||
* **Gate specific capabilities.** Keys such as `allowServerSSH` control whether the corresponding toggle is available in the app.
|
||||
|
||||
@@ -125,6 +125,8 @@ same registry key.
|
||||
|
||||
### Group Policy (on-prem AD / local gpedit)
|
||||
|
||||
For a full end-to-end walkthrough — domain Central Store, GPO creation, silent MSI install, and troubleshooting — see [Deploying NetBird with Group Policy (GPO)](/manage/peers/mdm-deployment/windows-gpo-deployment). The steps below cover the minimal local setup.
|
||||
|
||||
1. Copy the ADMX/ADML files into the system Policy Definitions store:
|
||||
- Place `netbird.admx` in `C:\Windows\PolicyDefinitions\`.
|
||||
- Place `netbird.adml` in `C:\Windows\PolicyDefinitions\en-US\`.
|
||||
|
||||
@@ -56,7 +56,7 @@ If you need only the CLI client without the desktop UI — for example, on headl
|
||||
#### One-command binary install
|
||||
|
||||
<Warning>
|
||||
The macOS binary tarballs from GitHub releases are **not Apple code-signed or notarized**. Only the official `.pkg` installer from [pkgs.netbird.io](https://pkgs.netbird.io) contains signed binaries. The unsigned binary will trigger Gatekeeper warnings and may be blocked by MDM policies. For managed fleet deployments, see [Building a CLI-Only .pkg for MDM Deployment](/manage/integrations/mdm-deployment/macos-cli-pkg-deployment) which includes steps for signing the binary with your own Developer ID.
|
||||
The macOS binary tarballs from GitHub releases are **not Apple code-signed or notarized**. Only the official `.pkg` installer from [pkgs.netbird.io](https://pkgs.netbird.io) contains signed binaries. The unsigned binary will trigger Gatekeeper warnings and may be blocked by MDM policies. For managed fleet deployments, see [Building a CLI-Only .pkg for MDM Deployment](/manage/peers/mdm-deployment/macos-cli-pkg-deployment) which includes steps for signing the binary with your own Developer ID.
|
||||
</Warning>
|
||||
|
||||
The install script supports a binary-only mode that downloads the tarball, extracts the `netbird` binary to `/usr/local/bin/`, and registers the launchd daemon:
|
||||
@@ -106,7 +106,7 @@ curl -fsSL https://pkgs.netbird.io/install.sh | USE_BIN_INSTALL=true SKIP_UI_APP
|
||||
This creates a launchd daemon at `/Library/LaunchDaemons/netbird.plist` that runs as root (required for managing the WireGuard network interface).
|
||||
|
||||
<Warning>
|
||||
Automatic updates via the NetBird dashboard do **not** work for binary-only installs. The auto-updater requires the official `.pkg` installer (it checks for the `io.netbird.client` package receipt). For binary installs, you must update manually or push updates through your MDM solution. See [Building a CLI-Only .pkg for MDM Deployment](/manage/integrations/mdm-deployment/macos-cli-pkg-deployment) for a managed approach.
|
||||
Automatic updates via the NetBird dashboard do **not** work for binary-only installs. The auto-updater requires the official `.pkg` installer (it checks for the `io.netbird.client` package receipt). For binary installs, you must update manually or push updates through your MDM solution. See [Building a CLI-Only .pkg for MDM Deployment](/manage/peers/mdm-deployment/macos-cli-pkg-deployment) for a managed approach.
|
||||
</Warning>
|
||||
|
||||
## Running NetBird with SSO Login
|
||||
|
||||
@@ -59,7 +59,7 @@ netbird up --setup-key <SETUP KEY>
|
||||
```
|
||||
|
||||
<Note>
|
||||
For MDM-specific deployment guides, see [Deploy with Intune](/manage/integrations/mdm-deployment/intune-netbird-integration) or [Deploy with Acronis](/manage/for-partners/acronis-integration).
|
||||
For MDM-specific deployment guides, see [Deploy with Intune](/manage/peers/mdm-deployment/intune-netbird-integration) or [Deploy with Acronis](/manage/for-partners/acronis-integration).
|
||||
</Note>
|
||||
|
||||
## Running NetBird with SSO Login
|
||||
|
||||
@@ -1,11 +1,17 @@
|
||||
export const description = 'Give resources behind NetBird routing peers friendly DNS names by pairing Custom DNS Zones with Networks: zone records, routing, policies, and verification.'
|
||||
|
||||
# DNS Aliases for Routed Networks
|
||||
|
||||
This guide explains how to use Custom DNS Zones with NetBird's Networks to provide easy-to-remember DNS names for resources in private
|
||||
This guide explains how to use [Custom DNS Zones](/manage/dns/custom-zones) with NetBird's Networks to provide easy-to-remember DNS names for resources in private
|
||||
networks.
|
||||
|
||||
|
||||
Custom DNS Zones work seamlessly with NetBird's [Networks](/manage/networks) feature to provide friendly DNS names for resources behind routing peers. This eliminates the need to remember IP addresses when accessing private network resources, creating a professional enterprise-like experience.
|
||||
|
||||
<Note>
|
||||
In this setup, NetBird hosts the DNS records itself. If you already run internal DNS servers (Active Directory, BIND, Unbound), point NetBird at them instead: see [Internal DNS Servers](/manage/dns/internal-dns-servers).
|
||||
</Note>
|
||||
|
||||
## How It Works
|
||||
|
||||
### The Challenge
|
||||
@@ -64,11 +70,13 @@ First, create a Custom DNS Zone to manage the DNS records for your private servi
|
||||
2. Click **Add Zone**.
|
||||
3. Configure the zone:
|
||||
- **Domain**: `netbird.internal`.
|
||||
- **Distribution Groups**: Select the groups that should have access to this DNS zone (e.g., `dev`, `internal-services`).
|
||||
- **Enable Search Domain**: Keep this enabled to allow using short names (e.g., `postgres` instead of `postgres.netbird.internal`).
|
||||
- **Distribution Groups**: Select the groups that should have access to this DNS zone (e.g., `dev`, `internal-services`). Include the **routing peer's group** as well: with [Routing Peer DNS Resolution](/manage/networks/how-routing-peers-work#routing-peer-dns-resolution) enabled (the default), clients forward queries for routed domains to the routing peer, which can only answer from zones it receives.
|
||||
- **Enable Search Domain**: Turn this on (it is off by default) to allow using short names (e.g., `postgres` instead of `postgres.netbird.internal`).
|
||||
4. Click **Add Zone**.
|
||||
|
||||
<img src="/docs-static/img/manage/dns/dns-aliases/zone-config.png" alt="Delete DNS Zone" className="imagewrapper-big"/>
|
||||
For the full reference on zone settings, record types, and limitations, see [Custom Zones](/manage/dns/custom-zones).
|
||||
|
||||
<img src="/docs-static/img/manage/dns/dns-aliases/zone-config.png" alt="Custom DNS Zone configuration" className="imagewrapper-big"/>
|
||||
|
||||
### Step 2: Add DNS Records
|
||||
|
||||
@@ -106,7 +114,7 @@ To enable access to your private resources, you need to set up a network with ro
|
||||
|
||||
#### Add Network Resources
|
||||
|
||||
Add a wildcard resource that will match all services in your DNS zone.
|
||||
Add a domain resource for each service in your DNS zone.
|
||||
|
||||
1. Click **Add Resource** and configure:
|
||||
- **Name**: `Internal Wiki`
|
||||
|
||||
@@ -5,6 +5,10 @@ import {Note, Warning} from "@/components/mdx"
|
||||
|
||||
When your network has on-premise DNS infrastructure — Active Directory, BIND, Unbound, or other internal DNS servers — you may need to configure NetBird to use them. This page covers when a nameserver configuration is needed and when it isn't.
|
||||
|
||||
<Note>
|
||||
If you don't run internal DNS servers and just want friendly names for private resources, NetBird can host the records itself. See [Custom Zones](/manage/dns/custom-zones) and the [DNS Aliases for Routed Networks](/manage/dns/dns-aliases-for-routed-networks) guide.
|
||||
</Note>
|
||||
|
||||
## When You Don't Need a Nameserver
|
||||
|
||||
If you just need access to a few internal resources by domain name, you don't need to configure a nameserver. Create a [Network resource](/manage/networks) with the internal domain name (e.g., `fileserver.corp.local`) and an [access control policy](/manage/access-control/manage-network-access) allowing your peers to reach it. The routing peer will resolve the DNS and route traffic to that resource. This works as long as the routing peer itself can resolve the domain.
|
||||
|
||||
@@ -27,7 +27,7 @@ or inconvenient customer-specific URLs.
|
||||
To apply for an MSP account, follow these steps:
|
||||
|
||||
* Ensure you have an active NetBird subscription ([Team plan](https://netbird.io/pricing) or higher).
|
||||
* Visit our MSP application form at [https://netbird.io/msp](https://netbird.io/demo?form=msp&utm_source=docs&utm_medium=docs&utm_content=msp-portal).
|
||||
* Visit our MSP Partner page at [https://netbird.io/use-cases/msp](https://netbird.io/use-cases/msp) and fill out the request form.
|
||||
* Complete the application form with your details and company information.
|
||||
|
||||
Submit the form for review by our team. Our team will evaluate your application and, if approved, grant you MSP status
|
||||
@@ -65,7 +65,7 @@ a TXT DNS record to the tenant's domain:
|
||||
<img src="/docs-static/img/manage/for-partners/msp-portal/add-new-tenant-verify-domain.png" alt="add-new-tenant-verify-domain" className="imagewrapper"/>
|
||||
</p>
|
||||
|
||||
4. Once the domain is verified, select a plan for the tenant.
|
||||
4. Once the domain is verified, select a plan for the tenant. Each tenant can subscribe to either a Team or a Business plan.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/for-partners/msp-portal/add-new-tenant-plan.png" alt="add-new-tenant-plan" className="imagewrapper"/>
|
||||
@@ -88,7 +88,7 @@ The current account owner will be prompted to grant this access the next time th
|
||||
</p>
|
||||
|
||||
<Note>
|
||||
When granted, the existing account owner role will change to admin and their subscription will be converted to a 3-days trial.
|
||||
When granted, the existing account owner's role will change to admin and their subscription will be converted to a 3-day trial. This gives you a short window to subscribe the tenant to a plan under your MSP account.
|
||||
</Note>
|
||||
|
||||
## Manage Tenant Networks
|
||||
@@ -127,6 +127,7 @@ This is because the MSP portal shows billable usage — meaning only active user
|
||||
(see [NetBird plans](/manage/settings/plans-and-billing#net-bird-plans) for more details).
|
||||
|
||||
The usage data is refreshed once per day and reflects the number of users and peers that will be included in your billing at the end of the cycle.
|
||||
You can export the usage data to CSV or PDF from the 'Tenants' overview page, or retrieve it programmatically via the [API](/api/guides/msp-api-access).
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/manage/for-partners/msp-portal/tenant-usage.png" alt="tenant-usage" className="imagewrapper-big"/>
|
||||
@@ -148,7 +149,7 @@ A single consolidated invoice is generated for your convenience, which you can d
|
||||
|
||||
To make things easier for you, all new tenant accounts come with a 14-day free trial. This gives you the perfect opportunity
|
||||
to showcase NetBird to your customers before committing to a paid plan. Simply select 'Continue with Free Trial' when
|
||||
setting up a new tenant plan. After the 14-day trial ends, the MSP account will no longer be able to make changes to the Tenant account. The interface will display a popup message indicating this restriction. However, all existing configurations within the Tenant account will remain intact, and network connections will continue to operate normally. Tenant administrators will no longer be able to make changes to the account as well and will see a notification instructing them to contact their MSP to proceed.
|
||||
setting up a new tenant plan. To continue after the trial, the tenant requires at minimum a Team plan with one user. After the 14-day trial ends, the MSP account will no longer be able to make changes to the Tenant account. The interface will display a popup message indicating this restriction. However, all existing configurations within the Tenant account will remain intact, and network connections will continue to operate normally. Tenant administrators will no longer be able to make changes to the account as well and will see a notification instructing them to contact their MSP to proceed.
|
||||
|
||||
## Delayed Tenant Domain Verification
|
||||
|
||||
@@ -174,4 +175,8 @@ This is the recommended approach as it gives the MSP engineer a proper identity
|
||||
|
||||
**Option 2: Add a Network and Routing Peer**
|
||||
|
||||
Add a NetBird Network and a routing peer on the client tenant's infrastructure under the MSP account.
|
||||
Add a NetBird Network and a routing peer on the client tenant's infrastructure under the MSP account.
|
||||
|
||||
---
|
||||
|
||||
Questions about the MSP partner program? Contact our partner team at [msp@netbird.io](mailto:msp@netbird.io).
|
||||
@@ -1,335 +0,0 @@
|
||||
# Access Internal Resources From Autoscaled Environments
|
||||
|
||||
For DevOps teams managing dynamic, scalable infrastructures, maintaining secure access to internal resources as environments scale up and down is challenging. Traditional network access methods often struggle to keep pace with the rapid changes in autoscaled environments, leading to security vulnerabilities, inefficient resource utilization, and complex management overhead.
|
||||
|
||||
Key challenges in managing network access for autoscaled environments like Kubernetes include:
|
||||
|
||||
* **Dynamic Resource Management**: As pods or containers scale up and down, maintaining consistent and secure network access becomes increasingly complex.
|
||||
* **Security Concerns**: Ensuring that only authorized resources have access to internal networks, especially in rapidly changing environments, is crucial but often difficult to manage.
|
||||
* **Efficient Resource Utilization**: Balancing network access with resource usage, particularly in autoscaled setups, requires careful planning and execution.
|
||||
|
||||
This guide introduces NetBird's solution for seamlessly managing network access in autoscaled Kubernetes environments by:
|
||||
|
||||
* **Automating Secure Access**: Demonstrating how NetBird setup keys can automatically provide secure network access to dynamically created resources.
|
||||
* **Enhancing Scalability**: Showcasing how NetBird integrates with Kubernetes' Horizontal Pod Autoscaler (HPA) to maintain network integrity during scaling events.
|
||||
* **Optimizing Resource Management**: Illustrating how NetBird efficiently manages network peers as resources scale up and down, ensuring optimal resource utilization.
|
||||
|
||||
Let's dive into the process of using NetBird to manage network access in an autoscaled Kubernetes environment.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To replicate this use case, you'll need:
|
||||
|
||||
* A [NetBird account](https://app.netbird.io/)
|
||||
* [NetBird](/get-started/install) installed on your local machine
|
||||
* A Kubernetes cluster (local or cloud-based)
|
||||
* `kubectl` installed and configured on your local machine
|
||||
* [Kubernetes metrics server](https://github.com/kubernetes-sigs/metrics-server)
|
||||
* The [IP address range assigned to the Pods](https://www.howtouselinux.com/post/find-the-ip-address-of-pod-in-kubernetes)
|
||||
|
||||
With these prerequisites in place, you'll be prepared to set up a secure network connection for autoscaled resources using NetBird by:
|
||||
|
||||
1. Creating a NetBird Setup Key for Kubernetes
|
||||
2. Configuring Routes for Internal Resource Access
|
||||
3. Setting Up Access Policies for Secure Communication
|
||||
4. Deploying a Sample Application with NetBird Agent
|
||||
5. Configuring Horizontal Pod Autoscaler (HPA)
|
||||
6. Observing NetBird's Dynamic Peer Management
|
||||
|
||||
This process will demonstrate how NetBird simplifies secure network access in autoscaled Kubernetes environments, automatically managing connections and access controls as resources scale up and down.
|
||||
|
||||
## 1. Creating a NetBird Setup Key for Kubernetes
|
||||
|
||||
The first step in this process is [creating a NetBird setup key](/manage/peers/register-machines-using-setup-keys) for your Kubernetes cluster. This setup key serves as a secure authentication token, allowing your cluster's pods to join your NetBird network seamlessly.
|
||||
|
||||
To create an appropriate setup key for this use case:
|
||||
|
||||
1. Log in to your NetBird dashboard.
|
||||
2. Navigate to `Settings` → `Setup Keys`.
|
||||
3. Click on `Add Setup Key` to create a new key.
|
||||
4. Provide a descriptive name for your key.
|
||||
5. Enable the `Reusable` option to allow multiple pods to use the same key.
|
||||
6. Activate the `Ephemeral Peers` toggle. This crucial setting automatically removes pods from the NetBird network if they've been offline for over 10 minutes, ensuring efficient resource management.
|
||||
7. Createthe new setup key by clicking `Create Setup Key`
|
||||
8. Ensure you take note of the generated setup key, you'll need it shortly.
|
||||
|
||||
Here's an example:
|
||||
|
||||
|
||||
|
||||
This configuration allows for dynamic management of your Kubernetes pods within the NetBird network. As your cluster scales up, new pods will seamlessly join the network. When pods are terminated or remain offline, they'll be automatically removed, maintaining a clean and efficient network topology.
|
||||
|
||||
## 2. Configuring Network Routes for Internal Resource Access
|
||||
|
||||
With the setup key in place, the next crucial step is creating a network route to enable access to the Pods within your Kubernetes cluster. For this tutorial, we'll create a straightforward network route that allows access to the Kubernetes cluster from your local machine.
|
||||
|
||||
Follow these steps to configure the network route:
|
||||
|
||||
In the NetBird dashboard, navigate to `Network Routing` → `Routes` and click on `Add Route` to create a new network route.
|
||||
|
||||
|
||||
|
||||
* In the `Network Range` field, enter the private IP range of your Kubernetes Pods. This is typically something like `10.0.0.0/16` for many Kubernetes clusters, but it may vary depending on your specific setup. If you're unsure, you can check this range in your Kubernetes configuration or consult your cluster administrator.
|
||||
* Navigate to the `Peer Group` tab and select your Kubernetes cluster's group as the routing peer. This group should contain all your cluster's nodes and will automatically include all the Pods running on these nodes.
|
||||
* In the `Distribution Groups` field, choose the group to which your local machine belongs.
|
||||
* Review your settings to ensure everything is correct. The route you're creating will allow traffic from your local machine (in the distribution group) to reach the Kubernetes Pods (in the peer group) via the specified network range.
|
||||
* Once you're satisfied with the configuration, click the `Continue` button.
|
||||
|
||||
|
||||
|
||||
Provide a descriptive name for your route, such as `NetBird K8s Demo`.
|
||||
|
||||
|
||||
|
||||
This setup creates a secure pathway for your local machine to communicate with the Pods in your Kubernetes cluster through the NetBird network. As new Pods are created or removed due to autoscaling, they'll automatically be included in or excluded from this route, maintaining seamless access without manual intervention.
|
||||
|
||||
|
||||
|
||||
## 3. Setting Up Access Policies for Secure Communication
|
||||
|
||||
NetBird's default access control policy automatically assigns all peers to the `All` group, enabling unrestricted bidirectional access between devices and users. While this default configuration allows immediate connectivity between your Kubernetes cluster and local machine, it's crucial to implement more granular access controls for enhanced security.
|
||||
|
||||
To create a new access policy:
|
||||
|
||||
1. Navigate to the `Access Control > Policies` section in your NetBird dashboard.
|
||||
2. Click on `Add Policy`.
|
||||
2. Create a new policy specifically for Kubernetes access:
|
||||
- Set the source as your local machine's group (e.g., `Local WS`)
|
||||
- Set the destination as your Kubernetes cluster group (e.g., `Kubernetes Cluster`)
|
||||
- Specify the protocols and ports required for your application if needed.
|
||||
|
||||
Your access policy must look similar to this:
|
||||
|
||||
|
||||
|
||||
|
||||
Click `Continue` and name your policy:
|
||||
|
||||
|
||||
|
||||
Once you save your policy, it is a good practice to disable or modify the default `All` group policy to prevent unrestricted access.
|
||||
|
||||
|
||||
|
||||
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](/manage/access-control/manage-network-access).
|
||||
|
||||
## 4. Deploying a Sample Application with NetBird Agent
|
||||
|
||||
With NetBird configured, it's time to deploy your application in Kubernetes. This process involves creating a dedicated namespace, securely storing the NetBird setup key, and deploying your application alongside the NetBird agent. Let's walk through each step:
|
||||
|
||||
Create a dedicated namespace to keep your NetBird-related resources organized and isolated:
|
||||
|
||||
```bash
|
||||
kubectl create namespace netbird
|
||||
```
|
||||
|
||||
Create a Kubernetes secret for the NetBird setup key:
|
||||
|
||||
```bash
|
||||
kubectl create secret generic netbird-setup-key -n netbird --from-literal=setup-key=YOUR_SETUP_KEY
|
||||
```
|
||||
|
||||
Remember to replace `YOUR_SETUP_KEY` with the actual setup key you created earlier. This method securely stores your key within Kubernetes.
|
||||
|
||||
Next, deploy your application. For this tutorial we'll use a [sample app](https://github.com/datawire/quote) that generates random quotes:
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: quote
|
||||
namespace: netbird
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: quote
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: quote
|
||||
spec:
|
||||
containers:
|
||||
- name: quote
|
||||
image: docker.io/datawire/quote:latest
|
||||
ports:
|
||||
- name: http
|
||||
containerPort: 8080
|
||||
resources:
|
||||
requests:
|
||||
cpu: 100m
|
||||
memory: 50Mi
|
||||
limits:
|
||||
cpu: 200m
|
||||
memory: 100Mi
|
||||
- name: netbird-agent
|
||||
image: netbirdio/netbird:latest
|
||||
env:
|
||||
- name: NB_SETUP_KEY
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: netbird-setup-key
|
||||
key: setup-key
|
||||
- name: NB_HOSTNAME
|
||||
valueFrom:
|
||||
fieldRef:
|
||||
fieldPath: metadata.name
|
||||
resources:
|
||||
requests:
|
||||
cpu: 50m
|
||||
memory: 64Mi
|
||||
limits:
|
||||
cpu: 100m
|
||||
memory: 128Mi
|
||||
securityContext:
|
||||
capabilities:
|
||||
add:
|
||||
- NET_ADMIN
|
||||
- SYS_RESOURCE
|
||||
- SYS_ADMIN
|
||||
|
||||
---
|
||||
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: quote
|
||||
namespace: netbird
|
||||
spec:
|
||||
ports:
|
||||
- name: http
|
||||
port: 80
|
||||
targetPort: 8080
|
||||
selector:
|
||||
app: quote
|
||||
```
|
||||
|
||||
This deployment creates a pod running both the `quote` app and the NetBird agent as a sidecar. The agent uses the setup key to automatically connect the pod to your NetBird network, enabling secure communication as defined by your routes and access policies.
|
||||
|
||||
Deploy the app by running the following:
|
||||
|
||||
```bash
|
||||
kubectl apply -f quote-app.yaml
|
||||
```
|
||||
|
||||
After a few seconds, the app will appear in NetBird's `Peers` dashboard. If you hover over the `Assigned Groups`, you'll notice the app automatically joined the group `Kubernetes Cluster` as expected.
|
||||
|
||||
|
||||
|
||||
## 5. Configuring Horizontal Pod Autoscaler (HPA)
|
||||
|
||||
To enable dynamic scaling of our application, we'll configure a [Horizontal Pod Autoscaler (HPA)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale). This YAML configuration sets up an HPA that scales based on CPU utilization:
|
||||
|
||||
```yaml
|
||||
apiVersion: autoscaling/v2
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata:
|
||||
name: quote-hpa
|
||||
namespace: netbird
|
||||
spec:
|
||||
scaleTargetRef:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: quote
|
||||
behavior:
|
||||
scaleDown:
|
||||
stabilizationWindowSeconds: 60
|
||||
minReplicas: 1
|
||||
maxReplicas: 3
|
||||
metrics:
|
||||
- type: Resource
|
||||
resource:
|
||||
name: cpu
|
||||
target:
|
||||
type: Utilization
|
||||
averageUtilization: 20
|
||||
```
|
||||
|
||||
Key points:
|
||||
|
||||
* We've set `minReplicas: 1` and `maxReplicas: 3` to limit scaling range.
|
||||
* `averageUtilization: 20` triggers scaling at 20% CPU usage, lower than the default for quicker demonstration.
|
||||
* `stabilizationWindowSeconds: 60` reduces the cool-down period for faster downscaling.
|
||||
|
||||
Apply this configuration with:
|
||||
|
||||
```bash
|
||||
kubectl apply -f quote-hpa.yaml
|
||||
```
|
||||
|
||||
Verify the resource was created by running:
|
||||
|
||||
```bash
|
||||
kubectl get hpa -n netbird
|
||||
```
|
||||
|
||||
The output should be similar to:
|
||||
|
||||
```bash
|
||||
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
|
||||
quote-hpa Deployment/quote cpu: 1%/20% 1 3 1 21m
|
||||
```
|
||||
|
||||
These settings accelerate scaling for tutorial purposes. In production, adjust these values based on your application's specific requirements and performance characteristics.
|
||||
|
||||
## 6. Observing NetBird's Dynamic Peer Management
|
||||
|
||||
Now that we've set up our application with NetBird integration and configured the HPA, we can observe how NetBird dynamically manages peers as the application scales. We'll use a simple load generator to trigger the autoscaling and monitor the results.
|
||||
|
||||
Open a new terminal window and run the following command to generate load:
|
||||
|
||||
```bash
|
||||
kubectl run -i --tty load-generator \
|
||||
--rm \
|
||||
--image=busybox \
|
||||
--restart=Never \
|
||||
-n netbird \
|
||||
-- /bin/sh -c "while sleep 0.001; do wget -q -O- http://quote; done" > /dev/null 2>&1
|
||||
```
|
||||
|
||||
This command creates a temporary pod that continuously sends requests to our application.
|
||||
|
||||
Now, in another terminal window, monitor the HPA's activity:
|
||||
|
||||
```bash
|
||||
kubectl get hpa -n netbird -w
|
||||
```
|
||||
|
||||
The `-w` flag enables watch mode, providing real-time updates on the HPA's status. The output should be similar to this:
|
||||
|
||||
```bash
|
||||
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
|
||||
quote-hpa Deployment/quote cpu: 2%/20% 1 3 1 23m
|
||||
quote-hpa Deployment/quote cpu: 26%/20% 1 3 1 24m
|
||||
quote-hpa Deployment/quote cpu: 29%/20% 1 3 2 24m
|
||||
quote-hpa Deployment/quote cpu: 41%/20% 1 3 2 24m
|
||||
quote-hpa Deployment/quote cpu: 63%/20% 1 3 3 25m
|
||||
quote-hpa Deployment/quote cpu: 38%/20% 1 3 3 25m
|
||||
quote-hpa Deployment/quote cpu: 17%/20% 1 3 3 25m
|
||||
quote-hpa Deployment/quote cpu: 1%/20% 1 3 2 30m
|
||||
quote-hpa Deployment/quote cpu: 1%/20% 1 3 1 31m
|
||||
quote-hpa Deployment/quote cpu: 1%/20% 1 3 1 32m
|
||||
```
|
||||
|
||||
If you go to NetBird `Peers` dashboard, you will see new peers automatically joining the network as pods scale up.
|
||||
|
||||
|
||||
|
||||
As you can see, all peers join the same group, meaning all share the same access policy you defined.
|
||||
|
||||
|
||||
|
||||
Conversely, when scaling down, peers are removed from the group and then terminated.
|
||||
|
||||
|
||||
|
||||
When ready, stop the load generator by pressing `Ctrl+C` in its terminal window; eventually, you will see only one app peer in the dashboard.
|
||||
|
||||
|
||||
|
||||
This demonstration showcases NetBird's powerful capabilities in seamlessly managing network connections within a dynamic, autoscaling Kubernetes environment. NetBird automatically adapts to your cluster's changing topology without any manual intervention, ensuring secure and efficient connectivity as pods scale up or down. This automation saves significant time and effort in network management and enhances your environment's security posture. By integrating NetBird, you're implementing a robust, scalable networking solution that keeps pace with your application's demands while maintaining strict access controls.
|
||||
|
||||
|
||||
|
||||
@@ -1,142 +0,0 @@
|
||||
# Peer Approval for Remote Worker Access with NetBird
|
||||
|
||||
For organizations embracing remote work, ensuring secure network access for distributed teams is a paramount challenge. Traditionally, VPNs and remote desktop solutions have been the standard for granting access to company resources. However, these methods often fall short in today's dynamic work environment, especially when dealing with freelancers and temporary workers.
|
||||
|
||||
The conventional approach to remote worker access presents several security and operational challenges:
|
||||
|
||||
* **Increased Security Risks**: Granting blanket access to network resources can expose sensitive data to potential breaches, especially when dealing with external collaborators.
|
||||
* **Device Management Complexity**: Ensuring that only authorized and secure devices connect to the network becomes increasingly difficult as the number of remote workers grows.
|
||||
* **Lack of Granular Control**: Traditional solutions often lack the flexibility to implement fine-grained access policies based on user roles and device trust levels.
|
||||
* **Scalability Issues**: As teams expand and contract, managing access for a fluctuating workforce can become a time-consuming and error-prone process.
|
||||
|
||||
This guide introduces NetBird's Peer Approval as a robust solution for secure remote worker access by:
|
||||
|
||||
* **Implementing Zero Trust Principles**: Ensuring that every device and user is verified before granting network access, regardless of their location.
|
||||
* **Simplifying Device Trust Management**: Providing a streamlined process for approving and managing trusted devices within the network.
|
||||
* **Enhancing Access Control**: Offering granular control over network resources, allowing organizations to tailor access based on user roles and device status.
|
||||
* **Improving Scalability**: Facilitating easy onboarding and offboarding of remote workers, including freelancers, without compromising network security.
|
||||
|
||||
Let's explore the step-by-step process of implementing [Peer Approval with NetBird](/manage/peers/approve-peers) to ensure that only trusted devices can access your network.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To replicate this use case, you'll need the following prerequisites:
|
||||
|
||||
* An main [NetBird account](https://app.netbird.io/) with administrative privileges.
|
||||
* A secondary email address not linked to any NetBird account to simulate the freelancer's email.
|
||||
* [NetBird installed](/get-started/install) on the main device.
|
||||
|
||||
With these prerequisites in place, you're ready to simulate granting network access to a temporary remote worker using NetBird's Peer Approval feature by:
|
||||
|
||||
1. Setting up NetBird's access control policies for enhanced security
|
||||
2. Enabling peer approval
|
||||
3. Inviting users to join your network
|
||||
4. Installing NetBird on the remote worker device
|
||||
5. Approving peers
|
||||
6. Automating peer approval with EDR integration (optional)
|
||||
|
||||
## 1. Setting Up NetBird's Access Control Policies For Enhanced Security
|
||||
|
||||
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`.
|
||||
|
||||
|
||||
|
||||
If necessary, you can also set [posture checks](/manage/access-control/posture-checks) for this policy.
|
||||
|
||||
|
||||
|
||||
Moreover, it is a best practice to disable the `Default` policy to enforce only restrictive, custom-defined access controls.
|
||||
|
||||
|
||||
|
||||
With appropriate access policies in place, you're ready to enable NetBird's Peer Approval feature.
|
||||
|
||||
## 2. Enabling Peer Approval
|
||||
|
||||
To enable peer approval, go to `Settings > Authentication` and activate the `Peer approval` toggle, then click `Save Changes`.
|
||||
|
||||
|
||||
|
||||
With `Peer Approval` activated, new members will see an `Approval required` message when joining. Administrators must grant access, ensuring only vetted users enter the NetBird network, thus enhancing overall security.
|
||||
|
||||
## 3. Inviting Users to Join Your Network
|
||||
|
||||
To invite a new user to join your NetBird network, go to `Team > Users` and click the `Invite User` button.
|
||||
|
||||
|
||||
|
||||
A pop-up window appears for new user registration. Enter the user's name, email address, and select the `Freelancers` group from the dropdown menu. NetBird's auto-assignment feature instantly links the new user to the `Freelancers` group upon network entry, automatically applying the associated access policy you just created.
|
||||
|
||||
|
||||
|
||||
After clicking `Send Invitation`, you'll return to the `Users` dashboard. Here, the new user appears with a `Pending` status, awaiting their acceptance of the invitation and any required approvals.
|
||||
|
||||
|
||||
|
||||
## 4. Installing NetBird On The Remote Worker Device
|
||||
|
||||
Access the secondary email account used to mimic the freelancer. In the inbox, locate the invitation email from NetBird. This email contains a secure link to join your organization's NetBird network, initiating the freelancer's onboarding process.
|
||||
|
||||
|
||||
|
||||
After clicking the invitation link, you'll be directed to NetBird's secure account creation page. Follow the on-screen instructions to create a new password.
|
||||
|
||||
|
||||
|
||||
Upon logging in, you'll arrive at NetBird's Peers dashboard. Locate and click the `Add Peer` button to initiate the [Getting Started](/get-started) Wizard, which guides you through the process of adding a new device to the network.
|
||||
|
||||
|
||||
|
||||
The wizard will detect your operating system and provide detailed step-by-step instructions on how to [install NetBird](/get-started/install).
|
||||
|
||||
|
||||
|
||||
During your initial connection to NetBird, a system dialog will appear requesting authorization. This prompt asks for permission to access your profile and email information, which is necessary for NetBird to establish your account and network access.
|
||||
|
||||
|
||||
|
||||
After completing the installation, your device will appear in the Peers dashboard. Hover over the `+1` in the `Assigned Groups` column to confirm the device has automaticaclly assigned to the `Freelancers` group as expected.
|
||||
|
||||
|
||||
|
||||
## 5. Approving Peers
|
||||
|
||||
Back to your primary account, you'll notice the newly added user's status is now displayed as `Active` in the `Users` dashboard. This status update confirms that the device has successfully added to the NetBird network and is ready for secure communication.
|
||||
|
||||
|
||||
|
||||
However, your approval is required before the user's device can fully connect to the NetBird network. To grant network access:
|
||||
|
||||
* Navigate to `Peers`
|
||||
* Locate the newly added device
|
||||
* Click the `Approve` button next to the device
|
||||
* Confirm the action when prompted
|
||||
|
||||
|
||||
|
||||
After approval, the device is granted full access to network resources allocated to the `Freelancers` group. The freelancer can now view all accessible network resources in their `Peers` dashboard:
|
||||
|
||||
|
||||
|
||||
Likewise, as an administrator, you can click on the user's device to see which resources and peers the freelancer has access to.
|
||||
|
||||
|
||||
|
||||
## 6. Automating Peer Approval with EDR Integration (optional)
|
||||
|
||||
NetBird's EDR (Endpoint Detection and Response) integration enhances network security by restricting access to devices managed by your organization's IT department. This feature synchronizes the list of devices managed by the EDR platform via API and verifies the presence of the EDR agent on each device. If the agent is not installed, access to the network is blocked.
|
||||
|
||||
Key aspects of NetBird's EDR integration:
|
||||
|
||||
* Supports [CrowdStrike Falcon](https://www.crowdstrike.com/products)
|
||||
* Allows selective application of EDR checks to specific device groups
|
||||
* Automates peer approval process for trusted devices
|
||||
* Available only in the cloud version of NetBird
|
||||
|
||||
To activate this feature, navigate to `Integrations > EDR` and activate the CrowdStrike integration toggle.
|
||||
|
||||
|
||||
|
||||
For more information regarding NetBird's EDR integration, refer to the [documentation](/manage/access-control/endpoint-detection-and-response)
|
||||
@@ -1,171 +0,0 @@
|
||||
# Secure Remote Web Server Access: SSH Without Port Exposure
|
||||
|
||||
For DevOps teams, secure remote web server access is a critical challenge. Traditionally, remote SSH access has been the go-to solution since it uses the SSH (Secure Shell) protocol to create encrypted network connections, ensuring data confidentiality and integrity while authenticating users and devices.
|
||||
|
||||
The problem is that conventional remote SSH access introduces security and operational challenges:
|
||||
|
||||
* **Increased Attack Surface**: Exposing SSH ports to the internet creates potential entry points for attackers, increasing the risk of unauthorized access and security breaches.
|
||||
* **Complex Network Configuration**: Configuring firewall rules and VPN setups for each server becomes unmanageable as the infrastructure scales.
|
||||
* **Cumbersome User Access Management**: Lack of centralized management makes enforcing consistent access policies and maintaining audit trails difficult.
|
||||
|
||||
This guide introduces NetBird as a secure solution for remote SSH access into a server without compromising safety by:
|
||||
|
||||
* **Enhancing Security**: Creating a secure overlay network that implements zero trust principles, eliminating the need for exposed inbound ports.
|
||||
* **Simplifying Network Management**: Simplifying network architecture and removing the need for complex firewall rules or VPN configurations.
|
||||
* **Centralizing Access Control**: Providing a unified platform for managing user access across all servers, simplifying policy enforcement and auditing.
|
||||
|
||||
This approach enhances security, simplifies operations, and improves scalability - key benefits for DevOps teams managing diverse environments and requiring frequent SSH into a server.
|
||||
|
||||
Let's dive into the step-by-step process of setting up this secure remote access solution with NetBird.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
For this use case, you'll need the following prerequisites:
|
||||
|
||||
* A [NetBird account](https://app.netbird.io/)
|
||||
* Single Sign-On (SSO) authentication set up with your preferred identity provider (optional but recommended for enhanced security).
|
||||
* [NetBird installed](/get-started/install) on your local machine.
|
||||
* A virtual machine running your target web server, configured to accept incoming SSH connections.
|
||||
|
||||
With prerequisites in place, you'll be prepared to establish an encrypted point-to-point connection between your local machine and the remote web server by:
|
||||
|
||||
1. Installing NetBird on the cloud VM hosting the web service
|
||||
2. Configuring NetBird's access control to manage permissions
|
||||
3. Establishing a secure SSH connection to access the internal web service
|
||||
|
||||
## 1. Installing NetBird on the Remote Server
|
||||
|
||||
Login to NetBird and navigate to `Peers` → `User Devices`. Ensure you see your local peer connected.
|
||||
|
||||
|
||||
|
||||
To add your remote web server to NetBird's peer network, first you need to generate a setup key:
|
||||
|
||||
* Navigate to `Settings` → `Setup Keys` in the left menu
|
||||
* Click `Create Setup Key`
|
||||
* Configure the key by assigning it a descriptive name (e.g., "Remote Web Server"), setting an expiration date, and defining auto-assigned groups (if required). Read the documentation for [detailed setup key configuration](/manage/peers/register-machines-using-setup-keys).
|
||||
* Copy the generated key to a secure location as you'll need it shortly
|
||||
|
||||
|
||||
|
||||
Next, install the NetBird agent on the VM.
|
||||
|
||||
* SSH into the remote server
|
||||
* Execute the following command:
|
||||
|
||||
```shell
|
||||
curl -fsSL https://pkgs.netbird.io/install.sh | sh
|
||||
```
|
||||
|
||||
The script downloads and installs the NetBird agent and starts the NetBird service. After installation, you'll see:
|
||||
|
||||
```shell
|
||||
Netbird service has been started
|
||||
Installation has been finished. To connect, you need to run NetBird by executing the following command:
|
||||
|
||||
netbird up
|
||||
```
|
||||
|
||||
However, since you'll use a setup key, you'll need to run the following command instead, replacing `<YOUR_SETUP_KEY>` with the key you generated::
|
||||
|
||||
```shell
|
||||
netbird up --setup-key <YOUR_SETUP_KEY>
|
||||
```
|
||||
|
||||
Check NetBird status by running:
|
||||
|
||||
```shell
|
||||
sudo netbird status
|
||||
```
|
||||
|
||||
The expected output is similar to the following:
|
||||
|
||||
```shell
|
||||
OS: linux/amd64
|
||||
Daemon version: 0.29.0
|
||||
CLI version: 0.29.0
|
||||
Management: Connected
|
||||
Signal: Connected
|
||||
Relays: 2/2 Available
|
||||
Nameservers: 0/0 Available
|
||||
FQDN: webserver.netbird.cloud
|
||||
NetBird IP: 100.85.105.240/16
|
||||
Interface type: Kernel
|
||||
Quantum resistance: false
|
||||
Routes: -
|
||||
Peers count: 0/0 Connected
|
||||
```
|
||||
|
||||
Now, go back to NetBird's `Peers` view and ensure your remote web server is connected.
|
||||
|
||||
|
||||
|
||||
## 2. Configuring NetBird Access Control Policies
|
||||
With both peers now connected to NetBird, the next step is to configure access control rules. This step is essential to define and restrict who can access the remote server, enhancing security by limiting connections to authorized users or devices only.
|
||||
|
||||
* 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](/manage/access-control/manage-network-access).
|
||||
|
||||
For this specific use case, we've implemented a simple access policy:
|
||||
|
||||
* **Source Group**: `Freelancers`
|
||||
* **Destination Group**: `Testing Environment`
|
||||
* **Protocol**: TCP
|
||||
* **Port**: 22 (SSH)
|
||||
* **Action**: Allow
|
||||
|
||||
This policy restricts SSH access to the `Testing Environment`, permitting only authorized members from the group `Freelancers` to connect.
|
||||
|
||||
|
||||
|
||||
After establishing the policy, assign peers to their respective groups. To add the remote web server to the `Testing Environment` group:
|
||||
|
||||
* Navigate to `Peers` in the left menu
|
||||
* Click on the name of the peer you want to edit, in this case, `webserver`
|
||||
* Find the `Assigned Groups` field and select `Testing Environment` from the dropdown list.
|
||||
|
||||
|
||||
|
||||
While you're there, take note of the IP addresses listed on the left. Use the quick copy buttons to get `NetBird IP-Address` and `Domain Name`. Alternatively, you can hover over the peer in the peers' list and copy the IP addresses as shown below:
|
||||
|
||||
|
||||
|
||||
With your remote server configured and the corresponding access policy enabled, the final step is to assign users to the appropriate group:
|
||||
|
||||
* Locate your user in the peers' list and click on it
|
||||
* Find the `Assigned Groups` field and select `Freelancers` from the dropdown list.
|
||||
|
||||
|
||||
|
||||
## 3. Establishing a Secure SSH Connection to Access the Internal Web Service
|
||||
|
||||
NetBird streamlines secure connections without traditional firewall complexities. Throughout this setup, you've implemented access controls without configuring a single firewall rule on any endpoint. This simplicity doesn't compromise security; instead, it enhances it through intuitive, group-based policies.
|
||||
|
||||
To verify your setup, simply ping the web server from a third-party device outside of the NetBird network using the web server's NetBird-assigned IP:
|
||||
|
||||
|
||||
|
||||
There is no response from the host. Now, ping the web server from your configured local machine:
|
||||
|
||||
|
||||
|
||||
As expected, all packets were transmitted. Now, you can securely SSH into your remote web server from your local peer, either using the NetBird-assigned domain name or IP address:
|
||||
|
||||
|
||||
|
||||
This straightforward test confirms your successful implementation of a secure, firewall-free connection to your remote web server via NetBird, demonstrating its power in simplifying robust network security.
|
||||
|
||||
|
||||
|
||||
## Get Started
|
||||
|
||||
<div>
|
||||
<Button name="button" className="button-5" onClick={() => window.open("https://netbird.io/pricing")}>Use NetBird</Button>
|
||||
</div>
|
||||
|
||||
- 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
|
||||
@@ -1,214 +0,0 @@
|
||||
# Add Servers to the Network with Setup Keys
|
||||
|
||||
For DevOps teams managing complex infrastructures, adding new servers or containers to the network is a persistent challenge. Traditionally, manual configuration and individual setup processes have been the norm, often leading to time-consuming, error-prone, and potentially insecure deployments.
|
||||
|
||||
The problem with conventional server and container network integration methods includes:
|
||||
|
||||
* **Time-Intensive Setup**: Manually configuring each new server or container for network access can be tedious and time-consuming, especially in rapidly scaling environments.
|
||||
* **Scalability Limitations**: As infrastructure grows, the complexity of managing network access for numerous servers and containers increases exponentially.
|
||||
* **Security Risks**: Manual processes can lead to human errors, potentially exposing servers to unauthorized access or creating security loopholes in the network.
|
||||
|
||||
This guide introduces [NetBird's Setup Keys](/manage/peers/register-machines-using-setup-keys) as an elegant solution for seamlessly and securely adding servers and containers to your network by:
|
||||
|
||||
* **Streamlining Deployment**: Providing a simple, automated way to connect new servers and containers to your NetBird network with minimal manual intervention.
|
||||
* **Facilitating Scalability**: Enabling rapid expansion of your network infrastructure without compromising on security or operational efficiency.
|
||||
* **Enhancing Security**: Implementing a secure, automated process that reduces the risk of human error and unauthorized access, strengthening your overall security posture.
|
||||
|
||||
This approach significantly reduces deployment time, ensures consistent and secure network configurations, and supports seamless scalability.
|
||||
|
||||
Let's dive into the step-by-step process of using [NetBird's Setup Keys](/manage/peers/register-machines-using-setup-keys) to securely add a server with a Docker container to your network.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
For this tutorial, you'll need the following prerequisites:
|
||||
|
||||
* A [NetBird account](https://app.netbird.io/)
|
||||
* The [NetBird agent](https://docs.netbird.io/get-started/install) installed in your local machine
|
||||
* A cloud-hosted virtual machine (VM) with SSH access
|
||||
* [Docker](https://www.docker.com/) installed on the cloud VM
|
||||
|
||||
With these prerequisites in place, you'll be prepared to set up a secure network connection using NetBird's Setup Keys by:
|
||||
|
||||
1. Creating a Setup Key in your NetBird account
|
||||
2. Provisioning a VM and installing NetBird using the Setup Key
|
||||
3. Deploying a Docker container on the VM
|
||||
4. Connecting the Docker container to the NetBird network using the Setup Key
|
||||
|
||||
This process will demonstrate how Setup Keys simplify and secure the addition of new servers and containers to your NetBird network.
|
||||
|
||||
## Creating a Setup Key in Your NetBird Account
|
||||
|
||||
To seamlessly integrate virtual machines or Docker containers into your NetBird network, you'll start by creating a setup key. While [NetBird's documentation offers comprehensive guidance on this process](https://docs.netbird.io/manage/peers/register-machines-using-setup-keys), let's quickly review the essential steps:
|
||||
|
||||
* Access your NetBird dashboard
|
||||
* Navigate to `Settings` → `Setup Keys`
|
||||
* Click the `Create Setup Key` button on the right
|
||||
* Name your key (e.g., "VM-Docker-Demo")
|
||||
* Set an expiration date (recommended for enhanced security)
|
||||
* Configure auto-assigned groups if needed
|
||||
* Click `Create Setup Key` to generate the setup key
|
||||
* Copy the generated key and store it securely as you'll need it for the next steps
|
||||
|
||||
Here's an example:
|
||||
|
||||
|
||||
|
||||
This setup key will serve as your secure passport for adding both your VM and Docker container to the NetBird network,
|
||||
ensuring a consistent integration process.
|
||||
|
||||
<Note>
|
||||
The Setup Key expiration date applies only to the key's validity period for adding new peers to the network.
|
||||
Once a peer is connected using the setup key, the expiration date does not affect the peer's network access.
|
||||
</Note>
|
||||
|
||||
## Provisioning a VM and Installing NetBird Using the Setup Key
|
||||
|
||||
After creating your setup key, the next step is to provision your VM and install NetBird:
|
||||
|
||||
* SSH into your cloud-hosted VM
|
||||
* [Install NetBird](https://docs.netbird.io/get-started/install) by running:
|
||||
|
||||
```bash
|
||||
curl -fsSL https://pkgs.netbird.io/install.sh | sh
|
||||
```
|
||||
|
||||
Once installation completes, connect to the NetBird network using your setup key:
|
||||
|
||||
```bash
|
||||
netbird up --setup-key <YOUR_SETUP_KEY>
|
||||
```
|
||||
|
||||
Verify NetBird's status:
|
||||
|
||||
```bash
|
||||
netbird status
|
||||
```
|
||||
|
||||
You should see output confirming the connection status, assigned IP, and peer information.
|
||||
|
||||
```bash
|
||||
OS: linux/amd64
|
||||
Daemon version: 0.29.4
|
||||
CLI version: 0.29.4
|
||||
Management: Connected
|
||||
Signal: Connected
|
||||
Relays: 2/2 Available
|
||||
Nameservers: 0/0 Available
|
||||
FQDN: docker-vm.netbird.cloud
|
||||
NetBird IP: 100.85.148.249/16
|
||||
Interface type: Kernel
|
||||
Quantum resistance: false
|
||||
Routes: -
|
||||
Peers count: 0/0 Connected
|
||||
```
|
||||
|
||||
You can also check the NetBird service status by running:
|
||||
|
||||
```bash
|
||||
sudo systemctl status netbird
|
||||
```
|
||||
|
||||
This should show the service as active and running.
|
||||
|
||||
```bash
|
||||
● netbird.service - A WireGuard-based mesh network that connects your devices into a single private network.
|
||||
Loaded: loaded (/etc/systemd/system/netbird.service; enabled; vendor preset: enabled)
|
||||
Active: active (running) since Tue 2024-09-24 19:22:56 UTC; 52s ago
|
||||
Main PID: 3819 (netbird)
|
||||
Tasks: 7 (limit: 1011)
|
||||
Memory: 26.3M
|
||||
CPU: 113ms
|
||||
CGroup: /system.slice/netbird.service
|
||||
└─3819 /usr/bin/netbird service run --config /etc/netbird/config.json --log-level info --daemon-ad
|
||||
```
|
||||
|
||||
Next, ensure NetBird starts automatically on boot:
|
||||
|
||||
```bash
|
||||
sudo systemctl enable netbird
|
||||
```
|
||||
|
||||
Finally, log into your NetBird dashboard and navigate to `Peers` to confirm your VM is listed and connected.
|
||||
|
||||
|
||||
|
||||
By using the setup key, you've securely added your VM to the NetBird network with minimal manual configuration, demonstrating the efficiency and security benefits of this approach.
|
||||
|
||||
## Deploying a Docker Container on the VM
|
||||
|
||||
To test NetBird's secure point-to-point connection, we'll deploy a simple Docker container with a Nginx-based web server serving a welcome page.
|
||||
|
||||
Create a directory for the Docker project:
|
||||
|
||||
```bash
|
||||
mkdir netbird-demo && cd netbird-demo
|
||||
```
|
||||
|
||||
Create a HTML file with the welcome message:
|
||||
|
||||
```bash
|
||||
echo "<html><body><h1>Welcome to NetBird Demo</h1><p>If you can see this, you've successfully connected to the container via NetBird.</p></body></html>" > index.html
|
||||
```
|
||||
|
||||
Create a `Dockerfile`:
|
||||
|
||||
```bash
|
||||
cat << EOF > Dockerfile
|
||||
FROM nginx:alpine
|
||||
COPY index.html /usr/share/nginx/html/index.html
|
||||
EOF
|
||||
```
|
||||
|
||||
Next, build and run the Docker container using the commands:
|
||||
|
||||
```bash
|
||||
docker build -t netbird-demo .
|
||||
docker run -d --name netbird-demo-container -p 8080:80 netbird-demo
|
||||
```
|
||||
|
||||
Notice that the container is accessible on port `8080` of the VM. You'll use this port to test the connection.
|
||||
|
||||
## Connecting the Docker Container to the NetBird Network Using the Setup Key
|
||||
|
||||
Now that your VM is connected to the NetBird secure network, you can verify the connection using either `curl` or your web browser. Simply use the NetBird-assigned IP address or domain for the VM to access the deployed web server.
|
||||
|
||||
To locate the NetBird-assigned IP or domain, go to `Peers` in your NetBird dashboard and hover your cursor over the VM's name.
|
||||
|
||||
|
||||
|
||||
Verify connectivity to the VM from any NetBird-connected device using:
|
||||
|
||||
```bash
|
||||
curl http://<NETBIRD_IP>:8080
|
||||
```
|
||||
|
||||
The expected output should be similar to the following:
|
||||
|
||||
```bash
|
||||
$ curl 100.85.148.249:8080
|
||||
<html><body><h1>Welcome to NetBird Demo</h1><p>If you can see this, you've successfully connected to the container via NetBird.</p></body></html>
|
||||
```
|
||||
|
||||
Alternatively, you can go to `http://VM_NETBIRD_DOMAIN:8080` using your browser:
|
||||
|
||||
|
||||
|
||||
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
|
||||
|
||||
To further enhance your network security, you can enable SSH access to your VM via an embedded NetBird SSH server.
|
||||
This feature allows you to securely access your VM with SSH without exposing it to the public internet and without the need
|
||||
for distributing and managing SSH keys. To enable NetBird SSH access, run the following command on your VM:
|
||||
|
||||
```bash
|
||||
sudo netbird up --allow-server-ssh
|
||||
```
|
||||
|
||||
You can then use the NetBird SSH client to connect to your VM:
|
||||
|
||||
```bash
|
||||
sudo netbird ssh <NETBIRD_DOMAIN | NETBIRD_IP>
|
||||
```
|
||||
|
||||
Summing up, NetBird's setup keys solve the challenge of securely connecting unattended resources, streamlining the integration of servers and containers without user intervention. For those looking to scale, the [NetBird API](https://docs.netbird.io/api/resources/setup-keys) offers powerful automation capabilities, allowing programmatic management of peers, setup keys, and access policies. These features combine to create a robust, secure, and easily manageable network infrastructure that adapts to your organization's needs.
|
||||
@@ -37,11 +37,11 @@ Let's create a policy that enables the `Development` team to access the `Servers
|
||||
- Set the source group to `Development` (or the appropriate team group synchronized from Entra ID) and the destination group to `Servers`
|
||||
- Configure the protocol and port settings based on required access patterns (e.g., TCP 22 for SSH access to servers)
|
||||
|
||||
|
||||
|
||||
|
||||
Provide a descriptive name for the policy, such as "Dev Team Server Access" that indicates its purpose, and click `Save` to create and activate the policy.
|
||||
|
||||
|
||||
|
||||
|
||||
This access policy will automatically apply to all devices enrolled in Intune that belong to users in the `Development` group (as synchronized from **Entra ID**), providing them secure access to designated resources while preventing lateral movement to unauthorized systems.
|
||||
|
||||
@@ -68,21 +68,21 @@ Using the Win32 method requires you to convert either NetBird's `.exe` or `.msi`
|
||||
|
||||
- Sign in to the [Microsoft Intune admin center](https://intune.microsoft.com), navigate to `Apps`, and click the `Windows` button.
|
||||
|
||||
|
||||
|
||||
|
||||
- Click the `+ Create` button to add a new Windows application
|
||||
|
||||
|
||||
|
||||
|
||||
- In the `App type` dropdown, select `Windows app (Win32)` and click `Select`
|
||||
|
||||
|
||||
|
||||
|
||||
- On the `Add App` screen, click `Select app package file` and browse to the location of the NetBird `.intunewin` file you created earlier
|
||||
|
||||
- Select the `.intunewin` file and click `OK`
|
||||
|
||||
|
||||
|
||||
|
||||
- On the `App information` tab, configure NetBird with the following values:
|
||||
|
||||
@@ -97,7 +97,7 @@ Using the Win32 method requires you to convert either NetBird's `.exe` or `.msi`
|
||||
|
||||
You can leave the rest of the fields empty.
|
||||
|
||||
|
||||
|
||||
|
||||
- Click `Next` to advance to the `Program` tab. Use the following commands in the install and uninstall fields:
|
||||
|
||||
@@ -108,14 +108,14 @@ You can leave the rest of the fields empty.
|
||||
|
||||
For this example, leave the rest of the configuration unchanged. Note that you can change the install behavior and users' ability to uninstall NetBird if required.
|
||||
|
||||
|
||||
|
||||
|
||||
- Click `Next` to advance to the `Requirements` tab. Here you can specify the architecture and minimum OS version required for installing NetBird. For instance:
|
||||
|
||||
- **Operating system architecture:** 64-bit
|
||||
- **Minimum operating system:** Windows 10 22H2
|
||||
|
||||
|
||||
|
||||
|
||||
- Click `Next` to advance to the `Detection rules` tab. Intune lets you choose between **using a custom detection script** or **manually configuring detection rules**. Select the latter and configure it as follows:
|
||||
|
||||
@@ -127,7 +127,7 @@ For this example, leave the rest of the configuration unchanged. Note that you c
|
||||
|
||||
Click `OK` when ready.
|
||||
|
||||
|
||||
|
||||
|
||||
For examples on registry-based detection rules, refer to [Intune documentation](https://learn.microsoft.com/en-us/intune/intune-service/apps/apps-win32-add#step-4-detection-rules)
|
||||
|
||||
@@ -137,19 +137,19 @@ For examples on registry-based detection rules, refer to [Intune documentation](
|
||||
|
||||
- On the `Assignments` tab, under `Required`, click `+ Add group`
|
||||
|
||||
|
||||
|
||||
|
||||
- Select the appropriate group that contains your users (like the `Development` group synchronized from Entra ID) and click `Select`
|
||||
|
||||
|
||||
|
||||
|
||||
- To continue, click `Next`. Review your configuration in the `Review + create` tab, then click `Create` to add NetBird to your Intune app catalog.
|
||||
|
||||
|
||||
|
||||
|
||||
- To verify that NetBird was added to Intune, navigate to `Apps > All Apps` to see your Windows applications:
|
||||
|
||||
|
||||
|
||||
|
||||
## Deploying NetBird as a Line-of-business (LOB) App
|
||||
|
||||
@@ -160,20 +160,20 @@ As a simpler alternative to the Win32 method described previously, you can deplo
|
||||
- Download the NetBird Windows MSI installer from the [NetBird installation documentation](https://docs.netbird.io/get-started/install/windows)
|
||||
- Sign in to the [Microsoft Intune admin center](https://intune.microsoft.com), navigate to `Apps`, and click the `Windows` button.
|
||||
|
||||
|
||||
|
||||
|
||||
- Click the `+ Create` button to add a new Windows application
|
||||
|
||||
|
||||
|
||||
|
||||
- In the `App type` dropdown, select `Line-of-business app` and click `Select`
|
||||
|
||||
|
||||
|
||||
|
||||
- On the `Add App` screen, click `Select app package file` and browse to the location of the NetBird MSI file you downloaded earlier
|
||||
- Select the NetBird MSI installer and click `OK`
|
||||
|
||||
|
||||
|
||||
|
||||
Click `Next` to configure NetBird with the following details:
|
||||
|
||||
@@ -189,27 +189,27 @@ Click `Next` to configure NetBird with the following details:
|
||||
|
||||
You can leave the rest of the fields empty.
|
||||
|
||||
|
||||
|
||||
|
||||
When ready, click `Next` to proceed to the `Assignments` tab. Under `Required`, click `+ Add group`
|
||||
|
||||
|
||||
|
||||
|
||||
- Select the appropriate group that contains your users (like the `Development` group synchronized from Entra ID) and click `Select`
|
||||
|
||||
|
||||
|
||||
|
||||
- To continue, click `Next`. Review your configuration in the `Review + create` tab, then click `Create` to add NetBird to your Intune app catalog.
|
||||
|
||||
|
||||
|
||||
|
||||
After adding NetBird, you'll see an overview screen for the NetBird app, showing deployment status and management options.
|
||||
|
||||
|
||||
|
||||
|
||||
To verify that NetBird was added to Intune, navigate to `Home > Apps | Windows` to see all your Windows applications:
|
||||
|
||||
|
||||
|
||||
|
||||
### Deploying NetBird to Other Platforms
|
||||
|
||||
@@ -38,11 +38,11 @@ For this tutorial, we'll create a policy that allows the `Support` team to acces
|
||||
* Set the source group to `Support` and the destination group to `Servers`.
|
||||
* Configure the appropriate protocol and port settings (e.g., TCP 22 for SSH access).
|
||||
|
||||
|
||||
|
||||
|
||||
Give the policy a descriptive name (e.g., "Support team remote access") and click `Save` to create the policy.
|
||||
|
||||
|
||||
|
||||
|
||||
With this policy in place, any device assigned to the `Support` group will gain access to the `Servers` group as defined in the Access Control Policy.
|
||||
|
||||
@@ -68,7 +68,7 @@ In the `Options` tab:
|
||||
|
||||
Click `Save` to finish. If you see the message "Availability pending", click `Refresh` to update the package status.
|
||||
|
||||
|
||||
|
||||
|
||||
### Creating a Policy for NetBird
|
||||
|
||||
@@ -84,29 +84,29 @@ In the **Trigger** options, check the following boxes:
|
||||
|
||||
These trigger selections ensure NetBird is installed promptly and remains current on all managed devices. Leave the remaining options as default.
|
||||
|
||||
|
||||
|
||||
|
||||
In the `Packages` section, click `Configure` and add the corresponding NetBird package:
|
||||
|
||||
|
||||
|
||||
|
||||
Accept the default values for **Distribution Point** and **Action**
|
||||
|
||||
|
||||
|
||||
|
||||
In the `Scope` tab, specify the target computers (all computers, specific computers or groups, etc.). For simplicity in this example, use `All Computers`.
|
||||
|
||||
|
||||
|
||||
|
||||
Optionally, in the `User Interaction` tab:
|
||||
* Enter messages to display before and after the policy runs.
|
||||
* This can help inform users about the installation process.
|
||||
|
||||
|
||||
|
||||
|
||||
Click `Save` to finish.
|
||||
|
||||
|
||||
|
||||
|
||||
This configuration ensures NetBird is installed as soon as any machine enrolls, maintaining security across your device fleet.
|
||||
|
||||
@@ -133,7 +133,7 @@ After setting up NetBird deployment policy in Jamf Pro, it's crucial to verify t
|
||||
* In the device details, go to the `Management` tab and locate the `Policies` section.
|
||||
* Look for the NetBird policy in the list of applied policies.
|
||||
|
||||
|
||||
|
||||
|
||||
If you see the NetBird policy listed, that would indicate that NetBird has been successfully installed on the device.
|
||||
|
||||
@@ -28,11 +28,11 @@ For instance, let's suppose you want to create a policy that allows the `Support
|
||||
* Set the source group to `Support` and the destination group to `Servers`.
|
||||
* Choose the appropriate protocol and port settings (e.g., TCP 22).
|
||||
|
||||
|
||||
|
||||
|
||||
Give the policy a descriptive name (e.g., Support team remote access) and click `Save` to create the policy.
|
||||
|
||||
|
||||
|
||||
|
||||
Now that you've configured NetBird, let's shift the focus to Kandji MDM integration and set up the automated deployment of NetBird on support team devices.
|
||||
|
||||
@@ -40,13 +40,13 @@ Now that you've configured NetBird, let's shift the focus to Kandji MDM integrat
|
||||
|
||||
Navigate to `Library` and click `Add new`. Then, find and select `Custom Apps` and click `Add & Configure` to deploy a new [Custom App](https://www.support.kandji.io/support/solutions/articles/72000559807-deploying-custom-apps).
|
||||
|
||||
|
||||
|
||||
|
||||
Give the Custom App a descriptive name (e.g., NetBird_vX.XX_Support_Team, where X.XX is the current version of NetBird being deployed). Scroll down to **Install Details**, where you'll see different options.
|
||||
|
||||
Select `Installer Package` to install NetBird using the official macOS package. Using a package ensures you're installing the exact same version on all devices. This example uses the Apple Silicon package that you can download [here](https://pkgs.netbird.io/macos/arm64). Drag the file to the `Installer Package` field box to upload it to Kandji MDM.
|
||||
|
||||
|
||||
|
||||
|
||||
Next, click on `Add Preinstall Script` and paste the following code:
|
||||
|
||||
@@ -141,41 +141,41 @@ For instance, you can [create tags](https://www.support.kandji.io/support/soluti
|
||||
|
||||
To create a tag in Kandji MDM, go to `DEVICES`, click on the hamburger menu at the top right, and select `Manage tags`:
|
||||
|
||||
|
||||
|
||||
|
||||
A new pop-up window will appear; click `+ Add tag`, enter a name for the tag (e.g., `Support`), and click `Save`.
|
||||
|
||||
|
||||
|
||||
|
||||
Navigate to the `BLUEPRINTS` section in Kandji and click the `New Blueprint` dropdown. Select `New Assignment Map` from the options. In the new window, you'll be presented with preconfigured templates or the option to start a new Blueprint from scratch. For this custom NetBird deployment, choose to start a new Blueprint from scratch.
|
||||
|
||||
|
||||
|
||||
|
||||
Give the Blueprint a descriptive name (e.g., NetBird_Apple_Silicon) and click `Create Blueprint`. This action will open Kandji's visual Blueprint builder, where you'll configure the deployment logic for NetBird.
|
||||
|
||||
Click `Edit assignments` to start editing the Blueprint.
|
||||
|
||||
|
||||
|
||||
|
||||
You'll see a list of apps from the library on the left, including the recently created NetBird custom app. To implement the deployment logic, hover over the `+` sign and click it to add a new conditional block. This block will determine which devices receive the NetBird installation based on specific criteria.
|
||||
|
||||
|
||||
|
||||
|
||||
Next, click the pencil icon to edit the rules.
|
||||
|
||||
|
||||
|
||||
|
||||
In the **Assignment Rules** window, configure the conditions for NetBird installation. Use the `Support` tag to trigger the deployment, ensuring NetBird is installed only on devices assigned to the support team. Press `Confirm` to continue.
|
||||
|
||||
|
||||
|
||||
|
||||
Back to the visual Blueprint builder, locate the NetBird custom app and drag it into the newly created conditional block. This action associates the NetBird installation with the specified deployment criteria for the support team.
|
||||
|
||||
|
||||
|
||||
|
||||
Click `Save` to update the Blueprint with the new logic. This action also assigns the Blueprint to the NetBird custom app, finalizing the deployment pipeline configuration.
|
||||
|
||||
|
||||
|
||||
|
||||
## Testing and Verifying the Automated Provisioning Pipeline
|
||||
|
||||
@@ -183,10 +183,10 @@ Kandji checks devices every 15 minutes by default, so any device tagged with `Su
|
||||
|
||||
To verify the deployment pipeline, navigate to `DEVICES` in Kandji, select an enrolled device, and click `Edit device details` > `Edit tags`. Assign the `Support` tag to trigger the NetBird installation.
|
||||
|
||||
|
||||
|
||||
|
||||
You can also confirm the process in NetBird. Log in to a NetBird account with administrative privileges, navigate to `Peers`, and look for the new device.
|
||||
|
||||
|
||||
|
||||
|
||||
In this tutorial, you've learned how to integrate NetBird's VPN solution with Kandji MDM for Apple devices. By configuring NetBird Access Policies, creating Kandji MDM Blueprints, and setting up an automated deployment pipeline, you've established a robust system for managing network access across your organization.
|
||||
@@ -212,10 +212,10 @@ xcrun stapler staple netbird-cli-${VERSION}.pkg
|
||||
|
||||
Upload the `.pkg` to your MDM solution and create a deployment policy. The exact steps vary by platform:
|
||||
|
||||
* **Jamf Pro**: Upload the package under `Settings > Computer Management > Packages`, then create a policy with appropriate triggers (enrollment, recurring check-in). See [Deploying NetBird with Jamf Pro](/manage/integrations/mdm-deployment/jamf-pro-netbird-integration) for detailed instructions.
|
||||
* **Kandji**: Create a Custom App library item with the `Installer Package` option. See [Deploying NetBird with Kandji](/manage/integrations/mdm-deployment/kandji-netbird-integration) for detailed instructions.
|
||||
* **Jamf Pro**: Upload the package under `Settings > Computer Management > Packages`, then create a policy with appropriate triggers (enrollment, recurring check-in). See [Deploying NetBird with Jamf Pro](/manage/peers/mdm-deployment/jamf-pro-netbird-integration) for detailed instructions.
|
||||
* **Kandji**: Create a Custom App library item with the `Installer Package` option. See [Deploying NetBird with Kandji](/manage/peers/mdm-deployment/kandji-netbird-integration) for detailed instructions.
|
||||
* **Munki**: Import the `.pkg` into your Munki repository using `munkiimport` and assign it to the appropriate manifest.
|
||||
* **Microsoft Intune**: Upload as a macOS LOB app. See [Deploying NetBird with Intune](/manage/integrations/mdm-deployment/intune-netbird-integration) for detailed instructions.
|
||||
* **Microsoft Intune**: Upload as a macOS LOB app. See [Deploying NetBird with Intune](/manage/peers/mdm-deployment/intune-netbird-integration) for detailed instructions.
|
||||
|
||||
## Managing updates
|
||||
|
||||
@@ -139,7 +139,7 @@ The install script's own log is at `%ProgramData%\NetBird\netbird-deploy.log`, a
|
||||
|
||||
## When not to use GPO
|
||||
|
||||
Group Policy only reaches domain-joined Windows machines. For Windows devices managed by Intune, use [Deploy with Intune](/manage/integrations/mdm-deployment/intune-netbird-integration) with the same ADMX or an OMA-URI profile. For macOS fleets, see [Jamf Pro](/manage/integrations/mdm-deployment/jamf-pro-netbird-integration) or [Kandji](/manage/integrations/mdm-deployment/kandji-netbird-integration). The registry values themselves are tool-agnostic, so anything that can write `HKLM\Software\Policies\NetBird` (SCCM, an RMM, a provisioning image) gives you the same enforcement without GPO.
|
||||
Group Policy only reaches domain-joined Windows machines. For Windows devices managed by Intune, use [Deploy with Intune](/manage/peers/mdm-deployment/intune-netbird-integration) with the same ADMX or an OMA-URI profile. For macOS fleets, see [Jamf Pro](/manage/peers/mdm-deployment/jamf-pro-netbird-integration) or [Kandji](/manage/peers/mdm-deployment/kandji-netbird-integration). The registry values themselves are tool-agnostic, so anything that can write `HKLM\Software\Policies\NetBird` (SCCM, an RMM, a provisioning image) gives you the same enforcement without GPO.
|
||||
|
||||
## Recap
|
||||
|
||||
@@ -140,7 +140,22 @@ kubectl apply -f deployment.yml
|
||||
```
|
||||
|
||||
<Note>
|
||||
In this example the setup key is passed as an environment variable. You should use a secret to pass the setup key.
|
||||
In this example the setup key is passed as a plain environment variable to keep the manifest short. In a real deployment, store it in a Kubernetes secret instead:
|
||||
|
||||
```shell
|
||||
kubectl create secret generic netbird-setup-key --from-literal=NB_SETUP_KEY=YOUR_SETUP_KEY
|
||||
```
|
||||
|
||||
Then reference it from the container spec:
|
||||
|
||||
```yaml
|
||||
env:
|
||||
- name: NB_SETUP_KEY
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: netbird-setup-key
|
||||
key: NB_SETUP_KEY
|
||||
```
|
||||
</Note>
|
||||
|
||||
### Step 5: Make the deployment highly available
|
||||
@@ -157,6 +172,8 @@ spec:
|
||||
replicas: 3
|
||||
...
|
||||
```
|
||||
|
||||
With more than one replica, a static `NB_HOSTNAME` would give every routing peer the same name in the dashboard. Remove the `NB_HOSTNAME` variable from the manifest instead — the client then falls back to the container hostname, which in Kubernetes is the pod name, so each replica registers under its own pod's name.
|
||||
Apply the updated deployment file to your Kubernetes cluster using the following command:
|
||||
```shell
|
||||
kubectl apply -f deployment.yml
|
||||
|
||||
Reference in New Issue
Block a user