And every definition of "zero trust networking" I can find still states that the point is that trust is something that's continually evaluated, which isn't the case if you're trusting someone simply because they're on your VPN.
The gist being that you are no longer making unverifiable trust assumptions about the identity of nodes connected to your network, as you have encrypted links between all nodes (not just between external nodes and a VPN gaetway to a non-zero-trust internal LAN) based on their verified identity and allowed access.
A node's identity can be verified by its public key, so you no longer implicitly need to trust that only known and expected nodes are plugged into the switch in the office (for example). I do not have to care about whether the physical network infrastructure can be trusted (zero trust) because I can verify the identity of all nodes.
This of course does not mean your entire architecture is zero trust. There are pretty much always trust decisions and assumptions somewhere, but that is why it's described as zero trust [mesh] networking, not zero trust complete end to end systems.
edit/aside: some people prefer the term "trust minimising" rather than zero trust to emphasise that there's always trust somewhere and you are just pushing it outside of some component or layer, and I agree this is probably a better/more accurate term.
> Tailscale describe zero trust networking more eloquently than I can...
Allow me to rephrase that for you ...
Tailscale, a company whose business model relies on selling Wireguard-based VPN products, tries to convince people/prospective customers that a VPN can be shoehorned into the Zero Trust concept.
If all you have is a hammer, everything looks like a nail as they say....
Agreed, I literally just replied to the comment below, that TS/WG approach of connecting devices is not zero trust as our focus should be on protecting 'services', not 'devices'. This requries micro-segmentation, least-privilege, attribute-based-access control, authenticate/authorise-before-connectivity as part of the overlay.
Tailscale does offer an ACL system[0] that allows protecting individual ports (which I assume is what is meant by services here?) and defaults to least-privilege (when ACLs are enabled, a node in the network cannot access other nodes by default). Though this configuration is centralized in the control plane. Does this not address some of those issues?
I'm not well-versed in zero-trust networking, so I may be missing something fundamental.
Good to know, the reference article does not talk about this and I was not aware of the feature set. My personal belief is that the term 'zero trust' comes in shades of grey. I personally believe that anything internet exposed is the lowest form, implementing a software-defined perimeter is the next, and that the final is to embed overlay networking into the application itself so we do not have to trust the WAN, LAN or even host OS network. I wrote a blog on this last year using Harry Potter analogies - https://netfoundry.io/demystifying-the-magic-of-zero-trust-w...
Exactly. I am awaare of Ockam, I work on the OpenZiti project (https://github.com/openziti). I believe our approaches to embed zero trust, private overlay networking into the app is the best way (with tunnelers for non-embedded where needed) so that we have the least trust in underlay networks (WAN/LAN/host OS network). Ziti is similar to Ockam at a high level (I am sure there are nuiance differences) though while we do not have a Rust SDK, we do have them for Golang, C, Java, Python, C#, Kotlin, ObjectiveC, JavaSript, NodeJS, etc.
Not quite. 802.1x provides an authentication mechanism to devices wishing to attach to a LAN or WLAN. Tailscale is describing to add E2E encryption between device to server so that if a malicious actor is on the underlay, they only see encrypted packets.
I would instead assert that Tailscale's/Wireguard's approach of connecting devices is not zero trust as our focus should be on protecting 'services', not 'devices'. This requries micro-segmentation, least-privilege, attribute-based-access control, authenticate/authorise-before-connectivity as part of the overlay.
It is more zero trust than it would otherwise be though. An RDP server with tailscale can reject by default packets coming from a LAN. And you can get ALC before a connection can be made.
