OAuth Provider + Tailscale Kubernetes operator compatibility

[almereyda]

Feature request

• Feature Request: Kubernetes Operator tailscale/tailscale#502 (comment)

Tailscale have recently released a Kubernetes operator for Tailscale clients.

• https://tailscale.com/kb/1236/kubernetes-operator/
• https://www.youtube.com/watch?v=PGfJ18cQzho

This issue is a about potential compatibility with its feature set. From a video published alongside the announcement, we learn that this makes use of Tailscale's OAuth provider at their upstream login server implementation.

Here we could elaborate, how Headscale could make the jump to compatibility by providing an OAuth provider implementation, and how to raise the need upstream (in the operator code base) for support of custom login servers in tailscale/k8s-operator, and passing those to the tailscale/tailscale containers.

https://github.com/tailscale/tailscale/blob/0e1403ec392bdc181a7de3de4f26ccb313e76323/cmd/k8s-operator/operator.go#L89-L93

[almereyda]

Increased support for an OAuth provider, bolstered with the already existing support for an OIDC client into an OIDC Relaying Party, could also help in providing short-lived access tokens for third-party Headscale API clients, such as the example of a Web UI #234, which in return would allow to refrain from creating static API tokens.

[madjam002]

The operator uses the Tailscale API which appears to be unrelated to the control plane API that Headscale mimics.

I think the only way to support Headscale with the operator is a complete fork or ground up implementation that uses the Headscale gRPC API instead, or for Headscale to also mimic the Tailscale REST API. https://tailscale.com/kb/1101/api/

[kradalby]

This is out of scope for this project.

[samcday]

This is out of scope for this project.

It seems to me that if such an API were to be contributed to the project, it would potentially eat into the moat that Tailscale is attempting to create with their proprietary control plane.

That is, if enough of the Tailscale.com Control Plane API and OAuth provider flow was implemented to support use-cases such as the Kubernetes operator, or the Terraform provider, it might pose a risk to Tailscale.com's bottom line.

I find it quite problematic (ethically, morally) that a salaried Tailscale employee has made the executive decision that this project cannot have such an API implementation.

It seems to me that Tailscale is attempting something of a "embrace, extend, extinguish" approach here. I'd like to know to what extent @juanfont still maintains and oversees this project?

I'm not trying to start a flame war here, I'm just observing what appears to be somewhat bad-faith behaviour from a commercial entity...

More pointedly, why can there not be an open issue in headscale that keeps the door open to folks contributing the bits necessary to implement the Tailscale API that the k8s-operator needs (all two methods)?

I get that Tailscale.com is unlikely to be eager to contribute such a thing, given the points I made earlier. But my understanding is stuff like the OIDC integration in headscale was contributed by kind strangers, who's to say such a thing couldn't happen here?

Just in case this comment gets deleted, if anyone is out there reading this and observes any further suspicious behavior, drop me a line at me@samcday.com - perhaps it's time to fork this project further from Tailscale.com control and conflict of interest.

[almereyda]

Yes and no. While I can follow the concern to double the API surface, as highlighted by me in #582 (comment) and someone else in tailscale/tailscale#11627 (comment), I am very confident in and grateful for the resources that Tailscale provide to the Headscale project.

I'm historically not involved enough to understand why the approach of a gRPC API was chosen; maybe just because someone wanted to learn something, but it's hard to argue for more features of a (not-only) voluntary project that is already compatible with the Tailscale FLOSS client to a certain degree.

I'm left wondering under which circumstances and conditions community contributions would likely be able to be accepted. The Vaultwarden SSO PR + temporary fork shows that a long time can go into a soft-fork, before it is of considerable quality for merging to a non-hesitant upstream. Maybe this is a good way to move forward with such feature-ladden work proposals anyway?

Let's not do the soft-fork before 0.23 is released, please ;) Else there's so much backporting work. Watching LXD and Incus dance around each other feature-wise is already rather enticing enough!

[majst01]

Another possibility would be to write a small api which serves the endpoints the tailscale operator expects, and talks to the headscale grpc api. Still a PR to the tailscale operator is required to make the tokenURL configurable. But as this would be a minimal change without adding extra dependencies, the chances to get this merged are there.

[Lite5h4dow]

or we could fork the operator and modify how it auths itself to align with headscale's capabilities, i may be wrong, but i think its just using the oauth provider to authenticate itself and those using it correct? if so, we could just add the auth checks to headscale in some fashion, and re-impliment the self authentication no?

[almereyda]

Good analysis. Eventually they would even allow a PR against the operator to support for both operation modes, given that Headscale is an officially sancitonned project by Tailscale Inc.