|
|
|
|
|
|
by crawshaw
2391 days ago
|
|
|
I have not heard the colloquial use of "zero trust" by service providers you mention. The baseline Tailscale product is not "you don't have to trust us" as we run the auth server. The variant of our product where you run your own auth server does have this property, but it is not the default arrangement. We do use "zero trust" in what you describe as the architectural sense, and I do not think leveraging WireGuard is a step backwards at all. When one node wants to communicate, it establishes a WireGuard tunnel to the node it wants to talk to. That WireGuard tunnel only moves packets for talking to a single node, to talk to another node you establish a new tunnel. There is (in our default and recommended setup) a 1-1 relationship between a public key for an endpoint its IP address. That public key was linked to a corporate SSO account by the auth server. That means when you send or receive a packet from the private IP range Tailscale manages, you know exactly the identity of the source or destination of that packet. If you configure a Tailscale node to route a subnet, you remove some of the BeyondCorp-style Zero Trust from your configuration. This feature exists to help companies transition to Zero Trust, and is not something I want to see as a final state for anyone's network. The end goal is Tailscale running on every node in the network. |
|
|
If the goal is to not use Tailscale as a standard SDN, and instead run it on every node with independent tunnels between nodes, when would I pick this vs using a service mesh that includes service discovery?
Is Tailscale intended to be a service mesh for the average Joe?
When creating an SDN or mesh, it's often preferable to separate local nodes (e.g. same datacenter) from remote nodes (e.g. different regions). How does Tailscale handle widely varying latency across the mesh?