mirror of
https://github.com/netbirdio/docs.git
synced 2026-10-20 12:39:04 +02:00
docs: unhyphenate "Zero Trust" across the docs (#740)
House style writes "Zero Trust" / "zero trust" without a hyphen in prose. Sweep all hyphenated prose occurrences under `src/pages/` to match. URL slugs (e.g. `/use-cases/security/implement-zero-trust`) and external links (CrowdStrike press release / blog URLs that include `zero-trust` as a path segment) are intentionally preserved.
This commit is contained in:
@@ -9,9 +9,9 @@ NetBird's access control system is built on Zero Trust security principles, ensu
|
||||
**NEW:** For a visual overview of your access policies and how peers, groups, and their relationships connect, check out the [**Control Center**](https://docs.netbird.io/manage/control-center) feature in NetBird. The Control Center provides an interactive graph view that makes it easy to understand your network's access structure at a glance.
|
||||
</Note>
|
||||
|
||||
## Zero-Trust Principles and NetBird
|
||||
## Zero Trust Principles and NetBird
|
||||
|
||||
Zero-trust networking operates on the principle of "never trust, always verify." Unlike traditional perimeter-based security models, zero-trust assumes that threats can exist both inside and outside the network. NetBird implements this through:
|
||||
Zero trust networking operates on the principle of "never trust, always verify." Unlike traditional perimeter-based security models, zero trust assumes that threats can exist both inside and outside the network. NetBird implements this through:
|
||||
|
||||
- **Deny-by-default behavior:** Without policies, no peer can communicate with another peer
|
||||
- **Explicit access grants:** Every connection must be explicitly allowed through a policy
|
||||
@@ -22,7 +22,7 @@ Zero-trust networking operates on the principle of "never trust, always verify."
|
||||
## Default ALL to ALL Policy (Not Recommended)
|
||||
|
||||
<Note>
|
||||
**TLDR:** NetBird automatically creates a Default policy that allows all devices to communicate with each other. While this helps with onboarding, the Default policy completely undermines zero-trust principles and should be removed once you create proper access control policies. Make sure to have replacement policies ready before deleting it, or all peer communication will stop.
|
||||
**TLDR:** NetBird automatically creates a Default policy that allows all devices to communicate with each other. While this helps with onboarding, the Default policy completely undermines zero trust principles and should be removed once you create proper access control policies. Make sure to have replacement policies ready before deleting it, or all peer communication will stop.
|
||||
</Note>
|
||||
|
||||
When you first create a NetBird account, a **Default policy** is automatically created that allows all peers to communicate with each other using any protocol. This policy exists because early NetBird users were confused and frustrated when their devices couldn't communicate—NetBird's deny-by-default security model meant nothing worked without policies defined, and users thought the platform was broken.
|
||||
@@ -33,7 +33,7 @@ When you first create a NetBird account, a **Default policy** is automatically c
|
||||
|
||||
The Default policy, which uses the special `All` group as both source and destination, solves this onboarding friction by letting new users immediately see NetBird working while they learn the platform.
|
||||
|
||||
However, **the Default policy completely undermines zero-trust security principles** and should be removed as soon as you're ready to implement proper access control. It violates the principle of least privilege, provides no network segmentation (a compromised device has direct access to everything), and allows all-to-all communication even after you create restrictive policies. Think of it as training wheels: helpful for getting started, but you should remove it when moving to production.
|
||||
However, **the Default policy completely undermines zero trust security principles** and should be removed as soon as you're ready to implement proper access control. It violates the principle of least privilege, provides no network segmentation (a compromised device has direct access to everything), and allows all-to-all communication even after you create restrictive policies. Think of it as training wheels: helpful for getting started, but you should remove it when moving to production.
|
||||
|
||||
## Understanding Groups
|
||||
|
||||
@@ -120,7 +120,7 @@ Even though NetBird treats all groups the same way technically, maintaining this
|
||||
- If you create an `engineering` → `engineering` policy to allow access, you've now granted all devices in that group access to each other, creating an unclear mesh where laptops can access servers AND servers can access laptops
|
||||
- It makes your access control messy and difficult to audit
|
||||
- You lose clarity about which devices are users vs. infrastructure
|
||||
- It violates zero-trust principles by not maintaining clear source and destination boundaries
|
||||
- It violates zero trust principles by not maintaining clear source and destination boundaries
|
||||
|
||||
**Correct approach:**
|
||||
✅ Add engineering team users into a `engineering-users` group and set machines or resources to a `engineering-servers` group. Create a setup key with `engineering-servers` as an auto-assigned group, then use that key when deploying servers. Finally, create a policy allowing `engineering-users` (source) to access `engineering-servers` (destination). This keeps your access control clear: users access servers, not the other way around.
|
||||
@@ -138,7 +138,7 @@ NetBird policies control network traffic by defining:
|
||||
|
||||
### Best Practice: Users as Source, Infrastructure as Destination
|
||||
|
||||
Following zero-trust principles, your policies should generally follow this pattern:
|
||||
Following zero trust principles, your policies should generally follow this pattern:
|
||||
|
||||
**✅ Recommended Pattern:**
|
||||
|
||||
@@ -199,7 +199,7 @@ While NetBird’s peer-to-peer technology allows servers to connect to laptops a
|
||||
|
||||
**Why avoid this?**
|
||||
|
||||
- Violates zero-trust principles
|
||||
- Violates zero trust principles
|
||||
- Increases attack surface
|
||||
- If a server is compromised, it could initiate connections to user devices
|
||||
- Doesn't align with typical network communication patterns
|
||||
@@ -410,7 +410,7 @@ Direction: One-way
|
||||
|
||||
## Conclusion
|
||||
|
||||
NetBird's access control system provides powerful, flexible tools for implementing zero-trust networking. By understanding the distinction between user groups and peer groups, following the principle of users-as-source and infrastructure-as-destination, and creating specific policies for each access requirement, you can build a secure, manageable network that follows security best practices.
|
||||
NetBird's access control system provides powerful, flexible tools for implementing zero trust networking. By understanding the distinction between user groups and peer groups, following the principle of users-as-source and infrastructure-as-destination, and creating specific policies for each access requirement, you can build a secure, manageable network that follows security best practices.
|
||||
|
||||
**Key takeaways:**
|
||||
|
||||
@@ -422,4 +422,4 @@ NetBird's access control system provides powerful, flexible tools for implementi
|
||||
6. **Implement posture checks** for sensitive resources
|
||||
7. **Document your policies** and review them regularly
|
||||
|
||||
By following these principles, you'll create a network that embodies zero-trust security while remaining manageable and understandable for your team.
|
||||
By following these principles, you'll create a network that embodies zero trust security while remaining manageable and understandable for your team.
|
||||
@@ -3,7 +3,7 @@
|
||||
NetBird empowers administrators to effectively manage and control access between resources (referred to as peers) using groups and access policies.
|
||||
These access policies define which peers or peer groups are allowed to connect, specify the protocols and ports available
|
||||
for these connections, and optionally incorporate posture checks. By integrating posture checks, NetBird enforces
|
||||
zero-trust principles, enabling dynamic and context-aware access control that adapts to the specific security needs of
|
||||
zero trust principles, enabling dynamic and context-aware access control that adapts to the specific security needs of
|
||||
your environment.
|
||||
|
||||
Watch our Access Control video on YouTube:
|
||||
|
||||
Reference in New Issue
Block a user