[HN Gopher] A new generation of Tailscale access controls
___________________________________________________________________
A new generation of Tailscale access controls
Author : ingve
Score : 136 points
Date : 2025-05-29 18:23 UTC (3 days ago)
(HTM) web link (tailscale.com)
(TXT) w3m dump (tailscale.com)
| mrbluecoat wrote:
| > When do I have to update all those policies to use the new
| syntax? ... You never have to update your existing rules to use
| the new grants syntax. We will support our original ACL syntax
| forever. ... When we say that Tailscale is a stable platform, we
| aren't kidding around.
|
| Nice business decision. Just like their reaction to Headscale,
| I'm reminded Tailscale 'gets it' when interacting with the dev
| community and why their popularity will continue to grow.
| gessha wrote:
| How did they react to Headscale? I must've missed the
| announcement.
| aspenmayer wrote:
| I'm not sure what they meant, but Tailscale links to
| Headscale and says this:
|
| > Headscale is an open source alternative to the Tailscale
| coordination server and can be self-hosted for a single
| tailnet. Headscale is a re-implemented version of the
| Tailscale coordination server, developed independently and
| completely separate from Tailscale. Headscale is a project
| that complements Tailscale -- with its own independent
| community of users and developers. Tailscale does not set
| Headscale's product direction or manage the community, and
| neither prohibits nor requires employees from contributing to
| Headscale.
|
| > Our opinion is that Headscale provides a valuable
| complement to Tailscale: It helps personal users better
| understand both how Tailscale works and how to run a
| coordination server at home. As such, Tailscale works with
| Headscale maintainers when making changes to Tailscale
| clients that might affect how the Headscale coordination
| server works, to ensure ongoing compatibility.
|
| https://tailscale.com/opensource#encouraging-headscale
| skydhash wrote:
| I think that you would've lose those users anyway, so at
| least leave a good impression on them as they can become
| advocate when they're in another context where Tailscale is
| the better solution.
| SOLAR_FIELDS wrote:
| The distilled version of this is that they let Headscale, a
| FOSS, use their proprietary client to connect to the
| Headscale server rather than Tailscale's. They don't need
| to allow this, they could easily disable that feature and
| have every right to, but they don't. This makes the
| development of Headscale a lot more straightforward since
| the entire client codebase is just removed from the
| equation.
| aseipp wrote:
| The tailscale client is not proprietary.
| jkaplowitz wrote:
| The GUIs for Windows, macOS, and iOS/iPadOS are
| proprietary.
| OJFord wrote:
| GP phrased it a confusing way around imo - proprietary or
| not, they don't need to give the client the capability to
| target a non-Tailscale server!
| dgb23 wrote:
| An excellent way to position yourself towards an open
| source alternative. Everything they do seems to be grounded
| in an engineering mindset and with respect to users.
| behnamoh wrote:
| What are some other companies like that?
|
| The ones that have an MBA-driven anti-user mindset IMO:
| Apple, Google, Microsoft, Meta, Oracle, Adobe, Nvidia,
| AMD
| sunshowers wrote:
| I think they've figured out a way to align their
| interests with what's truly good for their users. I'm
| sure a lot of their sales funnel is just nerds like us
| using Tailscale at home, and then bringing it to their
| employers.
|
| We're really happy Tailscale users at home. No bullshit,
| just works.
| baby_souffle wrote:
| > I think they've figured out a way to align their
| interests with what's truly good for their users. I'm
| sure a lot of their sales funnel is just nerds like us
| using Tailscale at home, and then bringing it to their
| employers.
|
| I can't say for certain (I do not work for TailScale, nor
| have I ever) but I suspect you are right.
|
| TailScale was _immediately_ surfaced in our team's "what
| could we replace open-vpn with?" conversation recently...
| precisely because most of us _are_ using it at home and
| have nothing but praise.
| xeonmc wrote:
| See https://tailscale.dev/blog/headscale-funnel
| matthewaveryusa wrote:
| They let it be. The decision is many-fold correct:
|
| 1) hobbiests that are obsessed with self-hosting can use it
| -- tailscale will never see a penny from them anyways
|
| 2) some businesses will consider headscale as an escape hatch
| de-risking if tailscale were to be purchased out by an
| extortionist (like broadcom's acquisition of VMware)
|
| 3) It signals they are doing business in a position of
| strength: businesses don't buy software, they buy solutions
| to problems
| Lammy wrote:
| > How did they react to Headscale? I must've missed the
| announcement.
|
| They hired the dev:
| https://tailscale.com/blog/opensource#the-open-source-
| coordi...
|
| Fun fact: Tailscale have an almost-assuredly-accurate count
| of Headscale users due to how few people disable the
| Tailscale client's telemetry which by default sends them
| real-time events about everything you do on a Headscale
| network. See KB1011: https://tailscale.com/kb/1011/log-mesh-
| traffic
|
| "Each Tailscale agent in your distributed network streams its
| logs to a central log server (at log.tailscale.io). This
| includes real-time events for open and close events for every
| inter-machine connection (TCP or UDP) on your network."
|
| It's possible to opt out of this spying on Unix/Windows/Mac
| by starting Tailscale with `--no-logs-no-support` or
| `TS_NO_LOGS_NO_SUPPORT=true` environment variable (see
| https://tailscale.com/kb/1011/log-mesh-traffic#opting-out-
| of...), but it is _not_ currently possible to opt out in the
| Android /iOS clients:
| https://github.com/tailscale/tailscale/issues/13174
|
| This is why they had the data telling them they should hire
| the Headscale dev to nip that competition in the bud before
| it had any chance to usurp their business by overtaking them
| in mindshare using their own client. Definitely a sound
| business decision, but it really _really_ irked me when I
| realized I was feeding Tailscale detailed usage data for
| everything I did on my supposedly """private""" Headscale
| network despite having no business relationship with them.
|
| For an example of how invasive this is for the average user,
| this person discovered Tailscale trying to collect ~18000
| data points per week about their network usage based on the
| number of blocked DNS requests for `log.tailscale.com`:
| https://github.com/tailscale/tailscale/issues/15326
|
| The privacy-adversarial behavior made me switch from
| Headscale to NetBird for my personal network now that it's
| available in FreeBSD Ports:
| https://www.freshports.org/security/netbird/
| ElectricalUnion wrote:
| > For an example of how invasive this is for the average
| user, this person discovered Tailscale trying to collect
| ~18000 data points per week about their network usage based
| on the number of blocked DNS requests for
| `log.tailscale.com`:
| https://github.com/tailscale/tailscale/issues/15326
|
| 18000 data points per week seems IMHO pretty low (only 1.7
| requests per minute for a whole network? Unlikely, even my
| Android phone does way more that 1.7 requests per minute
| just to ad networks, nevermind everything else on the
| network summed), it's probably way more.
|
| 18000 data points is also a lie, that's a different issue -
| the issue of UDP DNS sucking in general so your average
| application/OS keeps reissuing requests if they think the
| UDP packet got dropped.
| Lammy wrote:
| > only 1.7 requests per minute for a whole network?
|
| Connections != Requests
|
| Telemetry consisting of an open/close event pair would
| be, like, one entire SSH session, or one RDP session.
| Even HTTP has supported Keep-Alive since 1997.
| OJFord wrote:
| I reckon this (and that it can be used in conjunction with
| grants) implies they're translating the old config to the new
| format if it exists on the fly. Otherwise, if it involved
| running two things one in maintenance mode (and somehow
| ensuring they both take effect and don't conflict) it'd be
| ballsy to promise 'forever'.
|
| Although not sure why that's preferable to converting it once-
| off, so it's still not something a user has to worry about, but
| then the old way is done with.
| aatd86 wrote:
| There seems to be a missing comma in the first grant example. If
| I am not beffudled. At the end of the dst line.
|
| In fact, comma usage seems inconsistent for the last element of
| some of the nested objects.
|
| To be fair, I don't remember what's the json rule either and
| would need a quick lookup.
| stavros wrote:
| Yeah, the example that's missing the commas is wrong, if I'm
| not mistaken about their json parser. The optional comma at the
| end is fine with JSON5, which I think they're using, as that
| allows optional commas, comments, things like that.
| jrockway wrote:
| They use hujson: https://github.com/tailscale/hujson
|
| But it doesn't accept things like the example that omits an
| intermediate comma: { "foo": 42
| "bar": 123 } > hujson: line 3, column 5:
| invalid character '"' after object value (expecting ',' or '}')
| a_t48 wrote:
| Vaguely related - there's still no easy way to get at the
| email/user name of a user using tailscale ssh right? This is one
| of the things I really liked about teleport, you could use it to
| properly attribute git commits on shared machines, without any
| special setup on the user side.
| SOLAR_FIELDS wrote:
| When would I want this over a more generic solution like linking
| to an idp using something like keycloak? The upside is that its
| network level blocking, but it still requires modifying the
| application itself same as connecting an idp, correct? The
| downside of this approach is that it only works for internal
| access where your end users are on the tailnet
| mousetree wrote:
| It's at the network level. It will block clients from
| connecting to the destinations on the network. You don't need
| to modify any applications at the destination.
| SOLAR_FIELDS wrote:
| Am I misinterpreting like, the entire body of the article?
|
| > For private services inside your tailnet, like internal
| tools, implementing auth on every app is overkill. That's why
| we developed tsnet, a Go library that embeds Tailscale
| directly in your applications. This lets you see and react to
| the identity of every user who makes a request to your app.
| So, authentication is handled...what about authorization?
|
| The article then proceeds to show how to modify an
| application using tsnet to embed in the application. Which
| sounds a whole lot like modifying the application. The point
| might be that it's more straightforward to do this then gate
| behind something like keycloak, but fundamentally it still
| requires modifying the application
| mousetree wrote:
| Ah yes. This seems to be something new and entirely
| optional. They're saying that it might make sense to some
| to keep both network and application level authorization
| defined in one place. Personally, I'm with you in just
| using a normal SSO solution.
| miki123211 wrote:
| If you write internal apps, this is a lot easier to support.
|
| You don't have to think about redirects, sessions, cookies,
| syncing your users and their roles in TS and Keycloak,
| maintaining two separate policy files and all that.
| ElectricalUnion wrote:
| > When would I want this over a more generic solution like
| linking to an idp using something like keycloak
|
| I assume everyone using Tailscale are opting for "simple code
| and adminstration" instead of "let me pierce NAT and handle
| Wireguard tunelling myself". On that point of view, "Identity
| management" is part of "stuff" that Tailscale helps you in the
| first place. So why not use it as the "Identity management"
| solution as well?
|
| When you use `tailscale serve`, you get the headers Tailscale-
| User-Login, Tailscale-User-Name and Tailscale-User-Profile-Pic
| that identifies who connected thru the tailscale endpoint.
| https://tailscale.com/kb/1312/serve#identity-headers
|
| On a separete side note, if you had an exposed OpenID Connect
| service in the first place, you can use it as the Tailscale
| tailnet auth SSO: https://tailscale.com/kb/1240/sso-custom-oidc
| codethief wrote:
| Speaking of ACLs and grants, I wish Tailnet Lock[0] extended to
| those as well, i.e. allowed me to sign my tailnet policy file, so
| that if the coordination server and one of my nodes ever get
| compromised, the attacker can't just modify the policy file to
| access arbitrary services in my tailnet from the compromised
| node, including - in the worst case - SSH[1].
|
| [0]: https://tailscale.com/kb/1226/tailnet-lock
|
| [1]: https://tailscale.com/kb/1193/tailscale-ssh
___________________________________________________________________
(page generated 2025-06-01 23:00 UTC)