From aad38e086cfb37c60349864185490d72266ba193 Mon Sep 17 00:00:00 2001 From: thesabear Date: Tue, 1 Sep 2026 00:57:20 +0300 Subject: [PATCH] README.md: use a dedicated zero-trust diagram, stop reusing the doc's Was reusing netbird-zero-trust-mesh-topology.svg (the doc's detailed peer-topology diagram) in the README too - breaks this repo's own established convention of the README getting its own dedicated asset even when covering related material (see readme-trust-boundaries- blast-radius.svg vs architecture-overview-trust-depth.svg). New diagram is a simple perimeter-vs-zero-trust conceptual contrast, matching the README section's generalized framing rather than NetBird's specific implementation topology. --- README.md | 2 +- assets/readme-zero-trust-model.svg | 4 ++++ 2 files changed, 5 insertions(+), 1 deletion(-) create mode 100644 assets/readme-zero-trust-model.svg diff --git a/README.md b/README.md index 9465084..dc1526d 100644 --- a/README.md +++ b/README.md @@ -54,7 +54,7 @@ Zero trust is where enterprise security has been heading for years now — NIST This fleet doesn't just talk about that model — the four trust boundaries above are one expression of it, and remote/roaming access is a second, separate one, since "how do you reach the fleet from outside it" is a genuinely different problem from "how do services inside it talk to each other." That second problem is solved with a self-hosted zero-trust mesh (**NetBird**, WireGuard-based): every host and every device gets its own cryptographic identity, access is granted per-identity through explicit policy, and the mesh's own built-in allow-everything default is disabled — nothing crosses it unless a rule says so. -![The NetBird control plane sends thin coordination-only signals to every peer, while real data flows over direct peer-to-peer WireGuard tunnels that bypass the control plane entirely, with relay fallback only when a direct path isn't possible](assets/netbird-zero-trust-mesh-topology.svg) +![Perimeter model versus zero-trust model: on the left, anything inside one shared boundary can reach anything else inside it; on the right, every device has its own identity and only an explicit policy grants access, everything else blocked regardless of network position](assets/readme-zero-trust-model.svg) Full breakdown — the mesh-vs-VPN reasoning, the complete policy model (groups, scoped keys, peer approval, posture checks), the real bring-up story, and live evidence straight from the running system: [docs/netbird-zero-trust.md](docs/netbird-zero-trust.md). diff --git a/assets/readme-zero-trust-model.svg b/assets/readme-zero-trust-model.svg new file mode 100644 index 0000000..7913e7e --- /dev/null +++ b/assets/readme-zero-trust-model.svg @@ -0,0 +1,4 @@ + + + +
Perimeter model — trust by position
"inside the network"
Device A
Device B
Device C
anything in here reaches anything else in here
Zero-trust model — trust by identity
Device A
own identity
Device B
own identity
Device C
own identity
explicit policy
✕
✕
only what a policy explicitly allows — network position grants nothing
 \ No newline at end of file