Feature request: Use Tailscale for gokrazy API authorization

[joneskoo]

Currently tailscale uses HTTP basic authentication with username gokrazy and a password to authorize management (e.g. updates) of gokrazy.

The idea proposed here is that we'd use Tailscale in place of username/password for authorization. This would be nicer since browser would not prompt username/password, and more secure as it would prevent password from being phished / exposed via DNS hijacking / public WiFi as gokrazy by default doesn't use TLS. If the only way to access gokrazy is over Tailscale, it is not possible to reach it without being connected through Tailscale. No secrets would be needed.

To get the usability benefits, gokrazy would need to accept access without basic authentication (no username / password). This could be implemented either by running tsnet library and have gokrazy register as a node on Tailscale network (likely Tailscale authorization key for initial connection), or by running tailscale application and using tailscale serve.

It would also be possible to require capabilities in Tailscale ACL, e.g. gokrazy.org/cap/admin to do fine grained permissions, although probably most users would be happy with default ACL allowing everything (no capabilities) and it'd still enforce that only access from same Tailnet is allowed.

In summary, options are:

1. Simplest: if user connects via Tailscale, they're implicitly trusted (rely on Tailscale ACL)
2. Intermediate: gokrazy checks that connecting user is explicitly allowed. User owning the connecting device could be identified through Tailscale WhoIs.
3. Expert: Rely on Tailscale capabilities to define application level fine-grained permissions

I'd suggest to start with simplest form: "no basic authorization, only listen on Tailscale for management http interface" as that's closest to current basic authentication except better.

[stapelberg]

Yeah, skipping the basic auth check for requests coming in over the tailnet seems reasonable for personal tailnets. I do wonder if it should be opt-in, though, to not be surprising — if people deploy gokrazy in a company tailnet, they probably don’t want everyone in that tailnet to have access without password.

My general guidelines are that any integration should be done with minimal dependency footprint.

I think the tailscale client package is relatively light-weight, but maybe we can get somewhere without even pulling in extra dependencies: we already identify addresses as belonging to tailscale in gokrazy/ifaddr/ifaddr.go.

[joneskoo]

Hm. Should check if tailscale Whois works with tailscale serve; if we could add option to bind only to localhost and possibly optional Whois based identity allowlist, that would keep things very minimal.

Sounds like we think this is a reasonable idea, now only need to plan how to do it neatly without too deep changes and complexity.

Probably tailscale serve is preferred unless it turns out not to work, in which case maybe gokrazy module like wifi could implement the needed glue.

[JustinAzoff]

If you are using serve you don't necessarily need a separate whois call as serve can inject the identity headers:

https://tailscale.com/kb/1312/serve#identity-headers

In this sort of deployment there wouldn't be any tailscale specific code in the gocrazy webserver other than a configuration for what header to look for, i.e. Tailscale-User-Login