Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Real-world Tailscale business use case
11 points by jgilias 29 days ago | hide | past | favorite | 6 comments
I've been reading about the different zero-trust networking solutions (Tailscale, Zerotier, Nebula), and they seem great with peer to peer networking, strong encryption, UDP hole punching, fine grained role based access control, and so on. Tailscale especially goes so far as implying that other authentication and authorization solutions have been obviated by this techonology by writing in their blog about previous generation networking solutions the following:

"As a result, you end up having to add more layers of authentication, at the transport or application layers. Why do you need ssh or HTTPS? Because the network layer is too insecure to be trusted."

Ok, I'm willing to accept that an encrypted mesh network is so secure that you need neither the secure part in SSH nor PAM servers taking care of authentication. But then, how does this work in practice? To reify the confusion, here's a concrete example:

An organization uses Tailscale. There's 'server102' that is connected to the Tailscale network that all users of the `devops` team have access to. A new employee, Alice, joins the company. Sysadmins set up her SSO account, as well as makes her part of `devops` on Tailscale.

Alice gets her company computer, sets it up, connects to Tailscale, fires up her shell, types in `ssh alice.p.hacker@server102`, presses Enter.

What happens next?




I rolled out Tailscale for our network and loving it. "What happens next" is very well outlined in this article on their blog [1], and it's worth reading.

In my specific case, we were mainly on AWS and used Security Groups to control network access. "Allow SSH from these IPs, allow server connections between these EC2". This setup was fine for a small team, but the complexity grew exponentially. Alice just joined the company and started working from home with a dynamic IP - this messes up our allow-list based on static IPs. Then we started using Google Cloud, and guarding traffic between two VMs across two clouds is quite complex. Then we wanted to do automated deployments, so something from the outside needed to connect securely to our prod env.

Using Tailscale eliminated an entire category of complexity around identifying & securing inbound network connections, even if we ignore the NAT traversal magic. It's now a standard part of our stack, and I'm feeling a lot more in control of our network comms with minimal overheads - which is critical as we can focus on shipping instead of orchestrating.

[1] https://tailscale.com/blog/2021-05-life-of-a-packet/

edit: P.S. I picked Tailscale over the rest (Zero Tier / Nebula) because of a) the incredible strength of the team and b) funding + focus on the business. They have world-class talent and significant resources dedicated to this problem, so I believe they will make better progress over the next three years than the "best-effort" alternatives.


Ok, this may be a very silly question. But here goes.

In the above example, when Alice types `ssh alice.p.hacker@server102` and presses enter, is she now logged in? E.g., does tailscale takes care of having a user on the machine and assigning the known public key through some SAML/LDAP/PAM/sssd-ish magic?

Or does Alice gets 'access denied', then calls the sysadmins who still need to make a user for her on `server102`?

The second option would be understandable, but a bit of a bummer, as in that case the fancy RBAC rules have to be essentially recreated somewhere else for the application layer.


Alice will not be logged in into the server.

Tailscale allows Alice to merely connect to the IP/port, but whatever service is listening on that port still behaves as usual. So if you have an HTTP service that requires Basic auth, that's still required. If it's a MySQL server, still need an account there to login. If it's SSH, you still need a key/password - or whatever your SSH authentication mode is.

Think of Tailscale like a "jet bridge" securely connecting a bunch of buildings - you can use it to walk up to the front door safely (and Tailscale ACL controls traffic inside the tunnels), but to get inside you still need a key for that door (or whatever your auth method is).


Right, that's what I thought. This implies that you'd either need to recreate the access rules somewhere else for the application layer and use something like Teleport or some PAM server on top of Tailscale, or use some proverbial 'admin/pass123', if the Tailscale access guarantees feel strong enough.

Thanks!


The tailscale client can be queried to convert from tailscale ip to email. This could be used to track who is using the VPN service and to sign them into the protected web app. Grafana allows header auth params for example


Shameless plug but I was also interested in the magic behind these mesh networking tools, so I wrote my own toy version that was very much inspired by the tools you mentioned. I blogged about it here: https://www.samlewis.me/2021/07/creating-mesh-vpn-tool-for-f...

The short answer to your question though is that the packets are sent over a secure tunnel.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: