Expose LocalAPI clients

[kotx]

I want to build a Caddy module that depends on caddy-tailscale. Unfortunately, I can't access the LocalAPI instances from my code. Could these be exposed somehow, like through a app.LocalClient(node string) function?

[kotx]

Or perhaps we can expose https://pkg.go.dev/tailscale.com/tsnet#Server.LocalClient instead edited the issue title

[willnorris]

yeah, that was going to be my first question... do you actually need the whole tsnet.Server, or just part of it? Sounds like you mainly just want the LocalAPI client?

[kotx]

yeah, that was going to be my first question... do you actually need the whole tsnet.Server, or just part of it? Sounds like you mainly just want the LocalAPI client?

I mostly just want to call WhoIs to list app capabilities, so LocalAPI would work here.
Broader picture, I want to have a module look at the grants the caddy-tailscale instance has and generate tailscale listeners based on that- sort of like Tailscale Funnel.

[willnorris]

I've been meaning to add an issue here to expose grants through caddy-tailscale. Ideally, I'd like to expose them through placeholders so that then they could be used to create matchers with CEL expressions. But that's mostly focused on routing traffic based on grants and exposing them to a proxied application. Sounds like that probably wouldn't do quite what you're looking for?

You want to create tailscale listeners based on grants, or would they be public listeners? For a Tailscale Funnel like approach, I would think you'd want the latter? Although those requests wouldn't have grants since they're not over tailscale... so maybe I'm not quite getting what you're trying to do. Maybe it actually is closer to the thing I described above?

[kotx]

Hmm, the placeholder approach might not work- creating listeners based on placeholders is probably not supported in Caddy.

I want to expose public listeners that route to tailscale nodes (i.e. :80 { reverse_proxy tailscale-node:8080 { transport tailscale } }. But the caddy-tailscale instance needs to contain the grant to proxy to that node:

// Something like this:
"grants": [
  {
    "src": ["tag:caddy"], // the caddy-tailscale proxy
    "dst": ["100.101.102.103"], // upstreams, aka origins
    "app": {
      "some.capability/proxy": [
        { "type": "handle", "app": "http", "srcPort": 80, "dstPort": 8080 } // exposes :8080 with the http app
      ],
    }
  }
]

[willnorris]

So I don't think that would do what you want. That would expose the specified grants on the server running at 100.101.102.103 for connections coming from devices with tag:caddy. The device with tag:caddy wouldn't ever see those grants, nor would it see them ahead of time in order to use them to configure a public listener.

[willnorris]

If all you want to do is run your own funnel-style proxy that listens on a public host and proxies to a tailscale node, that's basically what https://github.com/tailscale/caddy-tailscale/blob/main/examples/transport.caddyfile#L24-L28 is doing (though just listening on localhost:8080... you'd need to have it listening publicly)

[kotx]

Ah, I think I misunderstood how grants work- thanks for pointing that out! I guess I will have to maintain some external state for my case instead of using the Tailscale ACL then.

Should I keep this issue open for other use cases or close it for now?

[kotx]

Actually I just realized I can reverse the grant src and dest and it shows up in the capmap!

[willnorris]

oh, now I get what you're doing! Instead of doing a whois lookup in the context of an inbound request (which is what it was originally designed for, but would be too late for what you're wanting), it sounds like you're doing a whois lookup on startup with a specific remote address to get the app capabilities. So you're effectively using grants as a means of pushing configuration values down to the server. Fascinating, and not at all what this was designed for, but I can see how it would work.

Though I still don't quite understand why you're not just using regular caddy configuration?

[kotx]

That's exactly it! (Node attrs or device posture would probably work too)
A regular caddy config would be fine for most cases, but I wanted something similar to Serve (i.e. as easily configurable as tailscale serve 3000) and dynamic. Mostly just a side project :P

Exposing a LocalAPI client would make things simpler because Tailscale configuration would be already defined by this module, avoiding the need for another tsnet instance.

[willnorris]

(that was actually @bradfitz's reply as well... "wouldn't nodeAttrs be easier?" 😄 ) But I suppose you'd need a localapi client either way.