Update docs Accessing entire domains within networks (#269)
* Update docs Accessing entire domains within networks * fix header --------- Co-authored-by: Maycon Santos <mlsmaycon@gmail.com>
|
After Width: | Height: | Size: 58 KiB |
|
After Width: | Height: | Size: 50 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 36 KiB |
|
After Width: | Height: | Size: 44 KiB |
|
After Width: | Height: | Size: 17 KiB |
|
After Width: | Height: | Size: 49 KiB |
|
After Width: | Height: | Size: 21 KiB |
|
After Width: | Height: | Size: 69 KiB |
|
After Width: | Height: | Size: 58 KiB |
|
After Width: | Height: | Size: 76 KiB |
|
After Width: | Height: | Size: 46 KiB |
|
After Width: | Height: | Size: 90 KiB |
|
After Width: | Height: | Size: 50 KiB |
|
After Width: | Height: | Size: 34 KiB |
|
After Width: | Height: | Size: 45 KiB |
|
After Width: | Height: | Size: 67 KiB |
|
After Width: | Height: | Size: 88 KiB |
|
After Width: | Height: | Size: 47 KiB |
|
After Width: | Height: | Size: 126 KiB |
@@ -1,119 +1,226 @@
|
||||
# Accessing entire domains within networks
|
||||
Companies often run entire development and internal environments using assigned domains that are not publicly accessible due to security reasons. Creating routing resources for these environments can quickly become a problem for
|
||||
DevOps and Platform teams because development teams may issue requests for new resources frequently. Taking that with the fact that some resources won't be within the same network, this can become a challenge to manage.
|
||||
|
||||
NetBird can help you configure access to these resources by routing your traffic through a routing peer configured with [Networks](/how-to/networks-concept) using [Wildcard domain resources](/how-to/networks-concept#resources).
|
||||
Companies often operate internal environments using assigned domains that remain inaccessible to the public for security and compliance reasons. Creating routing resources for these environments can quickly become a problem for DevOps and Platform teams, especially as different stakeholders frequently request new resources. Moreover, when these resources span across different networks, managing them becomes even more challenging.
|
||||
|
||||
## Example
|
||||
In the following scenario, we will create a new development network and add a wildcard domain resource for the entire `dev.example.com`
|
||||
to be routed using [Routing peers](/how-to/networks-concept#routing-peers) running in the network. All developers will be able to access the development environment using the `Network` configuration.
|
||||
NetBird's [Networks](https://docs.netbird.io/how-to/networks-concept) streamlines this process, allowing organizations to configure secure access to internal resources efficiently using [Wildcard domain resources](https://docs.netbird.io/how-to/networks-concept#resources). This reduces the administrative burden on IT teams and enhances overall productivity.
|
||||
|
||||
### Pre-requisites
|
||||
## Example Use Case Scenario
|
||||
|
||||
#### Configure Nameservers
|
||||
In order for the the following steps to work, you need to configure Nameservers to resolve all domain queries in your NetBird account. See the [Manage DNS in your network](/how-to/manage-dns-in-your-network) guide for more information.
|
||||
In this scenario, an AI software company needs secure access to its internal domains, encompassing both development and AI model training environments. This integration is vital for maintaining robust internal network security while ensuring seamless domain access across the entire network infrastructure.
|
||||
|
||||
### Configuration Overview
|
||||
|
||||
1. **Development Environment**:
|
||||
- Wildcard Domain: `*.dev.example.com`
|
||||
- Purpose: Provides developers with access to a shared workspace for code development, testing, and collaboration.
|
||||
|
||||
2. **AI Model Training Environment**:
|
||||
- Wildcard Domain: `*.ai.example.com`
|
||||
- Purpose: Houses sensitive AI models and datasets, requiring restricted access to ensure security and integrity.
|
||||
|
||||
### 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.
|
||||
- **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
|
||||
|
||||
To effectively access entire domains within your internal networks using NetBird, ensure the following pre-requisites are met:
|
||||
|
||||
- **NetBird Clients**: Install [NetBird clients](https://docs.netbird.io/how-to/getting-started) on all devices used by developers and data scientists. This is essential to establish secure connectivity to your internal resources.
|
||||
- **Routing Peers**: Configure [NetBird routing peers](https://docs.netbird.io/how-to/networks-concept#routing-peers) within your network infrastructure using [setup keys](https://docs.netbird.io/how-to/setup-keys-add-servers-to-network). Routing peers facilitate traffic routing across different network segments, ensuring seamless access to both internal domains.
|
||||
- **Nameserver Configuration**: Ensure that your Nameservers are properly configured within your NetBird account to resolve all domain queries. This step is critical for enabling seamless domain name resolution across your network, facilitating efficient connectivity to both your development and AI model training environments. For detailed instructions, refer to the [Manage DNS in Your Network](https://docs.netbird.io/how-to/manage-dns).
|
||||
|
||||
## Enabling DNS Wildcard Routing
|
||||
|
||||
Enabling DNS wildcard routing is crucial for handling sub-domain requests across your development and AI model training environments, ensuring seamless access for developers and data scientists to all necessary subdomains without requiring additional configuration.
|
||||
|
||||
Note that enabling DNS wildcard routing shifts the DNS resolution responsibility from the local client system to the routing peer. Compared to the previous behavior of DNS routes via network routes, this transition facilitates enhanced access control rules available in newer NetBird client versions and optimizes traffic management by directing queries to the nearest routing peer service. This setup simplifies the DNS management process and bolsters security and network efficiency.
|
||||
|
||||
#### Enable DNS wildcard routing
|
||||
When you configure wildcard domains as resources, you need to enable DNS wildcard routing. Which has an additional effect in comparison to the previous DNS routes behavior from Network routes; it switches the DNS resolution to the routing peer instead of the local client system.
|
||||
This is also useful for regular DNS routes when you want to resolve the domain names using the routing peer's IP infrastructure, which will allow for more restricted access control rules in newer versions of the clients(**1**) and for the traffic to go to a near routing peer service.
|
||||
<Note>
|
||||
(1) Support for more restricted rules will be available in future releases.
|
||||
</Note>
|
||||
You can enable DNS resolution on the routing peer by accessing your account `Settings` > `Networks` > Enable DNS wildcard routing. See example below:
|
||||
<p>
|
||||
<img src="/docs-static/img/how-to-guides/networks/settings-1.png" alt="settings-acl" className="imagewrapper-big"/>
|
||||
</p>
|
||||
|
||||
To enable DNS wildcard routing in your NetBird account, follow these steps:
|
||||
|
||||
* Navigate to `Settings` > `Networks` within your NetBird account.
|
||||
* `Enable DNS wildcard routing` by toggling the appropriate setting. This will allow your network to resolve all subdomains under a specified domain.
|
||||
|
||||

|
||||
|
||||
<Note>
|
||||
The `Enable DNS wildcard routing` is supported by routing peers and routing clients running version 0.35.0 or later.
|
||||
The `Enable DNS wildcard routing` is supported by routing peers and routing clients running version `0.35.0` or later.
|
||||
Once the feature is enabled, you may need to restart your routing peers and clients to apply the changes.
|
||||
</Note>
|
||||
|
||||
### Create a Network
|
||||
To create a Network, navigate to the `Networks` > `Networks` section in the NetBird dashboard:
|
||||
## Setting Up Developers' Network Environment
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/how-to-guides/networks/new-network.png" alt="new-net" className="imagewrapper-big"/>
|
||||
</p>
|
||||
To create a network for the developer environment:
|
||||
|
||||
Click on `Add Network` to follow a Wizard that will guide you through the steps to create a network and add resources to it.
|
||||
* Navigate to `Networks` > `Networks` in NetBird's dashboard.
|
||||
* Click the `Add Network` button.
|
||||
* Give a descriptive name to the network, e.g., `Development Network`. Optionally, add a description.
|
||||
* Click `Add Network` to continue.
|
||||
|
||||
First, we fill out the network Name and Description as shown in the image below and click `Continue`:
|
||||

|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/how-to-guides/networks/new-dev-network-1.png" alt="new-dev-net1" className="imagewrapper"/>
|
||||
</p>
|
||||
### Adding Routing Peers
|
||||
|
||||
### Add a routing peer
|
||||
Next we are asked to add a routing peer to the network. Let's click on `Add routing peer` and select a node from that VPC:
|
||||
Click `Add Routing Peer` to make accessible the resources within this network to the developers.
|
||||
|
||||
<p>
|
||||
<img src="/docs-static/img/how-to-guides/networks/add-wild-routing-peer-1.png" alt="new-wild-routing-peer-1" className="imagewrapper"/>
|
||||
</p>
|
||||
Click on `Continue` and then accept the defaults to add a routing peer by clicking on `Add Routing Peer`:
|
||||
<p>
|
||||
<img src="/docs-static/img/how-to-guides/networks/add-routing-peer-2.png" alt="new-routing-peer-2" className="imagewrapper"/>
|
||||
</p>
|
||||

|
||||
|
||||
### Add a resource
|
||||
Following the guide, we are asked to add a new resource.
|
||||
You will see two tabs: `Routing Peers` and `Peer Group`.
|
||||
|
||||
Click on `Add Resource` and enter the domain name of the `Development domain` in this case, `*.dev.example.com`:
|
||||
<p>
|
||||
<img src="/docs-static/img/how-to-guides/networks/add-wild-domain-resource-1.png" alt="new-wild-resource-1" className="imagewrapper"/>
|
||||
</p>
|
||||
* Select `Routing Peers` to add one peer at a time to the network.
|
||||
* Select `Peer Group` to enable high availability by adding multiple peers to the network.
|
||||
* Click `Continue` once ready.
|
||||
|
||||
We can also assign a group to this resource; in this example, we will assign the group `development-domains` to it. This way, we can create a policy that allows the development team to access the domains in the environment.
|
||||

|
||||
|
||||
### Add an access control policy
|
||||
Next, in the guide, we will be asked to create an access control policy. Here, we will create a policy that allows access to the `development-domains` group of the `*.dev.example.com`
|
||||
resource to peers in the `Developers` group. They will be granted all traffic to domains in the development environment.
|
||||
In the `Advanced Settings` tab:
|
||||
|
||||
Click on `Create Policy` and fill out the fields as shown in the image below:
|
||||
<p>
|
||||
<img src="/docs-static/img/how-to-guides/networks/add-wild-domain-resource-acl-1.png" alt="new-resource-acl-1" className="imagewrapper-big"/>
|
||||
</p>
|
||||
* Set `Masquerade` if you want to access private networks without configuring local routers or other devices.
|
||||
* Set the `Metric` to prioritize routers, using lower values for higher priority peers.
|
||||
* When ready, click `Add Routing Peer`.
|
||||
|
||||
Click on `Continue` 2 times and then click on `Add Policy` to save the policy:
|
||||
<p>
|
||||
<img src="/docs-static/img/how-to-guides/networks/add-wild-domain-resource-acl-2.png" alt="new-resource-acl-2" className="imagewrapper-big"/>
|
||||
</p>
|
||||

|
||||
|
||||
### View the network
|
||||
After completing the wizard, you will be able to see the network you just created in the Networks list:
|
||||
<p>
|
||||
<img src="/docs-static/img/how-to-guides/networks/view-wild-network-1.png" alt="view-wild-network-1" className="imagewrapper-big"/>
|
||||
</p>
|
||||
### Adding a Wildcard Domain Resource
|
||||
|
||||
To access a detailed view of the network, click on the network name:
|
||||
<p>
|
||||
<img src="/docs-static/img/how-to-guides/networks/view-wild-network-2.png" alt="view-wild-network-2" className="imagewrapper-big"/>
|
||||
</p>
|
||||
Click `Add Resource` to create the wildcard domain resource.
|
||||
|
||||
You can edit or add more resources or routing peers to the network by clicking on the `Edit` buttons of each section in the detailed view.
|
||||

|
||||
|
||||
### Add a regular domain resource
|
||||
A wildcard domain won't cover the entire domain by itself because the wildcard character `*` only covers subdomains after the `.`. If you need to cover the entire domain, you can additionally add a regular domain resource to the network.
|
||||
* Give the resource a descriptive name, e.g., `Development Wildcard Domain`
|
||||
* Enter the wildcard domain for this environment, e.g., `*.dev.example.com`.
|
||||
* Under `Assigned Groups`, select or create a group, e.g., `Development Domain`. This group will be used to create an access policy to allow developers access to all subdomains ending with `.dev.example.com`.
|
||||
* Click `Add Resource` when ready.
|
||||
|
||||
This time, let's add a domain from the main Networks list view. Click on the `Add Resource` button:
|
||||
<p>
|
||||
<img src="/docs-static/img/how-to-guides/networks/view-wild-network-3.png" alt="view-wild-network-3" className="imagewrapper-big"/>
|
||||
</p>
|
||||
Then, enter the domain name of the `Regular domain` in this case, `dev.example.com`:
|
||||
<p>
|
||||
<img src="/docs-static/img/how-to-guides/networks/add-wild-domain-resource-2.png" alt="new-wild-resource-2" className="imagewrapper"/>
|
||||
</p>
|
||||

|
||||
|
||||
We can also assign the same group to this resource, allowing us to reuse the previous access control policy for the `development-domains` group.
|
||||
### Creating an Access Policy
|
||||
|
||||
With the steps above, we created resources that allow the development team to access the entire `dev.example.com` domain and the `*.dev.example.com` subdomains using the same policy.
|
||||
Click `Create Policy` to grant developers access to `*.dev.example.com`.
|
||||
|
||||
## Get started
|
||||
<p float="center" >
|
||||
<Button name="button" className="button-5" onClick={() => window.open("https://netbird.io/pricing")}>Use NetBird</Button>
|
||||
</p>
|
||||

|
||||
|
||||
- Make sure to [star us on GitHub](https://github.com/netbirdio/netbird)
|
||||
- Follow us [on Twitter](https://twitter.com/netbird)
|
||||
- Join our [Slack Channel](https://join.slack.com/t/netbirdio/shared_invite/zt-2utg2ncdz-W7LEB6toRBLE1Jca37dYpg)
|
||||
- NetBird [latest release](https://github.com/netbirdio/netbird/releases) on GitHub
|
||||
* Under `Protocol`, leave `ALL`.
|
||||
* Under `Source` choose the group corresponding to developers, e.g., `Developers`.
|
||||
* The `Destination` is automatically set to the group you used when creating the resource, e.g., `Development Domain`.
|
||||
|
||||

|
||||
|
||||
* Click `Continue` to set `Posture Checks`. This step is optional, meaning you can click `Continue` for this example.
|
||||
* Provide a descriptive name for the policy, e.g., `Development Wildcard Domain Policy`.
|
||||
* Click `Add Policy` to finish.
|
||||
|
||||

|
||||
|
||||
Now that the development environment is set up, you can streamline the process of creating new resources using NetBird.
|
||||
|
||||
### Adding a Regular Domain Resource
|
||||
|
||||
The wildcard domain you configured, `*.dev.example.com`, only covers subdomains following the `.` (dot). Therefore, you need to configure a primary domain alongside your wildcard domain within your network settings. This dual approach guarantees that all levels of your domain hierarchy are adequately resolved and accessible.
|
||||
|
||||
Suppose you want to create the regular domain `dev.example.com`.
|
||||
|
||||
* Navigate to `Networks` > `Development Network` and click `Add Resource`.
|
||||
|
||||

|
||||
|
||||
* Provide an appropriate name for the resource, such as `Development Regular Domain`.
|
||||
* In the `Address` field, enter the regular domain `dev.example.com`.
|
||||
* Under `Assigned Groups` select the same group used for the wildcard domain, e.g., `Development Domain`.
|
||||
* Click `Add Resource` to continue.
|
||||
|
||||

|
||||
|
||||
That's it! Since you used the group `Development Domain`, NetBird will automatically configure for you routing peers and access policies, granting your developers the necessary access permissions.
|
||||
|
||||

|
||||
|
||||
You can confirm the configuration by listing the available networks using the command `netbird networks ls` from any developer workstation. The output should resemble the following:
|
||||
|
||||
```bash
|
||||
$ netbird networks ls
|
||||
Available Networks:
|
||||
|
||||
- ID: Development Regular Domain
|
||||
Domains: dev.example.com
|
||||
Status: Selected
|
||||
Resolved IPs:
|
||||
[example.com]: 93.184.215.14, 2606:2800:21f:cb07:6820:80da:af6b:8b2c
|
||||
|
||||
- ID: Development Wildcard Domain
|
||||
Domains: *.dev.example.com
|
||||
Status: Selected
|
||||
Resolved IPs: -
|
||||
```
|
||||
|
||||
## Creating AI Model Training Network
|
||||
|
||||
For our use case, data scientists operate from different network segments or diverse geographical locations. Using the same steps previously outlined, you can overcome the challenges associated with this scenario by creating a new network with its corresponding routing peers, resources, and access policies.
|
||||
|
||||
From the `Networks` screen, click `Add Network` to set up an appropriate network for your data scientists:
|
||||
|
||||

|
||||
|
||||
As with developers, you can configure a single routing peer or a group of routing peers for high availability:
|
||||
|
||||

|
||||
|
||||
You can also set up a wildcard domain resource for this environment:
|
||||
|
||||

|
||||
|
||||
And establish an access policy tailored to your data scientists:
|
||||
|
||||

|
||||
|
||||
You will need a regular domain, too; simply create the corresponding resource. The overview of your new network might resemble the following:
|
||||
|
||||

|
||||
|
||||
Need a new subdomain for testing the latest model? From NetBird's Networks screen, just click `Add Resource`, name it, enter the desired subdomain, and assign it to the appropriate group for this environment:
|
||||
|
||||

|
||||
|
||||
In summary, you can easily add, remove, and edit network resources from the Networks dashboard.
|
||||
|
||||

|
||||
|
||||
With this setup, all members of the `Data Scientists` group have access to `ai.example.com` and its subdomains:
|
||||
|
||||
```bash
|
||||
$ netbird networks ls
|
||||
Available Networks:
|
||||
|
||||
- ID: AI Model Training Wildcard Domain
|
||||
Domains: *.ai.example.com
|
||||
Status: Selected
|
||||
Resolved IPs: -
|
||||
|
||||
- ID: AI Regular Domain
|
||||
Domains: ai.example.com
|
||||
Status: Selected
|
||||
Resolved IPs: -
|
||||
|
||||
- ID: DataSage Model
|
||||
Domains: datasage.ai.example.com
|
||||
Status: Selected
|
||||
Resolved IPs: -
|
||||
|
||||
- ID: NeuroPulse Model
|
||||
Domains: neuropulse.ai.example.com
|
||||
Status: Selected
|
||||
Resolved IPs: -
|
||||
|
||||
- ID: QuantumNet Model
|
||||
Domains: quantumnet.ai.example.com
|
||||
Status: Selected
|
||||
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.
|
||||